Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>
>>I have been performing some performance analysis of the Avalon Excalibur code, and I
>discovered
>>some serious points of thread contention. In a web environment, there can be as
>many as 150
>>threads (or more) if the web server uses simple thread per connection technology
>>(most common aproach for Java based servers like Tomcat). I expanded the Profile
>tests to work
>>using 100 threads. The default pooling implementation has some serious slowdown due
>to thread
>>contention.
>>
>
> Berin, I spent several *months* finetuning the thread-pool code that was
> used in Apache JServ 1.0 (and is still there, used in both IBM WebSphere
> and Oracle Application Server). I remember that I got a report from
> Alcatel that they were using it with loads up to 12000 req/sec.
:) And how many *threads* running simultaneously?
Remember, Requests/Second != cuncurrent threads
Apache HTTPD in it's default configuration will run up to 150 processess,
and when there are more connections than processess, it will make further
requests wait.
12000 req/sec translates to 12.5 ms/request with 150 processes/threads.
It also translates to 41.6ms/request with 500 processes/threads.
(In another mail I will post my formula for scaling requirements)
> Guess that if you need something clean and scalable, that's the way to
> go :)
>
> [I proposed this a while back but you and Peter tought it was too
> complex.... but I still like mine more :) but I'm biased]
( Aren't we all ;P )
I think the implementations we have now fit that bill--clean and scalable.
The question remains about the ECM itself yet. I haven't had time to write
the profiling tests yet.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
