Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of jak-tomcat-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: tomcat-dev@jakarta.apache.org
From: Costin Manolache <cmanolache@yahoo.com>
Subject: Re: Tomcat performance patch (in development) to reduce
 concurrency...
Date: Wed, 04 May 2005 09:38:02 -0700
Lines: 35
Message-ID: <d5atcf$h72$1@sea.gmane.org>
References: <45f524a105040720503ee0f802@mail.gmail.com>
 <1115214123.6587.17.camel@smarlow.dnsdhcp.wal.novell.com>
 <4278F3BD.6010007@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
In-Reply-To: <4278F3BD.6010007@apache.org>
Sender: news <news@sea.gmane.org>

Mladen Turk wrote:
> Scott Marlow wrote:
> 
>> Hi,
>> I wonder if anyone has any feedback on a performance change that I am
>> working on making.
> 
> 
> Can you compare the performance of you code with the standard
> implementation when the concurrency is lower then maxThreads
> value?
> 
> I see no point to make patches that will deal with cases presuming
> that the concurrency is always higher then the actual number of
> worker threads available.
> 
> IMHO this is a bad design approach for the http applications,
> and NIO performance is a proof of that.
> It might help in cases where you have a very very slow clients.
> In any other case the thread context switching will kill
> the performance thought.
> 
> Further more I don't see how can you avoid keep-alive connection
> problems without using a thread-per-connection model.
> The point is that with 100 keep-alive connections you will still
> have 100 busy threads.

Why ? 100 keep alive connections doesn't mean 100 active requests,
in real servers there are many 'keep alive' connections that are just
waiting for the next request.

In all servers I know, concurrency was higher than the configured number 
of workers  - at peak time, at least, where performance matters.

Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org