Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3C6BC9B1.7000108@apache.org>
Date: Thu, 14 Feb 2002 09:29:05 -0500
From: Berin Loritsch <bloritsch@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.8) Gecko/20020204
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Possible points of scalibility issues
References: <3C6AC8BA.305@apache.org> <3C6BAF54.72CF193E@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org