Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4DC16A18.5040601@apache.org>
Date: Wed, 04 May 2011 16:00:40 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB;
 rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: BIO performance issues
References: <4DC05F39.2060102@apache.org> <4DC160B4.5010505@kippdata.de>
In-Reply-To: <4DC160B4.5010505@kippdata.de>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

On 04/05/2011 15:20, Rainer Jung wrote:
> I hope the following is not too long and confusing ...

Not at all.

> On 03.05.2011 22:02, Mark Thomas wrote:
>> Solution A
>> ----------
>> NIO is designed to handle this using a poller. That isn't available to
>> BIO so I attempted to simulate it. That generated excessive CPU load so
>> I do not think simulated polling is the tight solution.
> 
> I expect generating the SocketTimeoutException is expensive, because the
> JVM has to generate the stack information. The rate of the Exception
> when handling mostly keep-alive (extreme case) is your "poll" timeout
> times the number of threads, e.g. 100ms timeout times 200 threads is
> 2000 exceptions per second. Even if there is another reason for the high
> CPU load, I expect it to be roughly proportional to the poll rate.

<snip/>

> Do we see a cpu time and thread blocking time efficient way of handling
> many keep-alive connections? I don't see any API, that would help here.
> Of course one could try to build a hyprid "blocking for normal
> processing but non-blocking for keep-alive" thing, but since we already
> have NIO I would also support recommending NIO for keep-alive.

The only API I see is NIO and that is what the NIO connector is for. I
don't see an efficient way to do this with the BIO API.

> Switching the default from BIO to NIO is a big change, but only after we
> switch will we find the last buglets and problems arising under rare
> conditions. So if we want to switch, we should do it very soon. Doing it
> late in the TC 7 cycle would be bad.

I think we are beyond the point where we can change the default HTTP
connector to NIO for Tomcat 7 (as much as part of me really, really
wants to).

> Lastly: APR uses server to server connections, as does HTTP when using a
> reverse proxy in front of Tomcat. In those cases we have much fewer
> connections with a higher rate of requests per connection. There
> maxThreads == maxConnections is fine (and even the 75% rule could be
> switched off).

It is. The 75% limit only applies to the HTTP BIO connector.

> So for this scenario it would be nice to not drop BIO, at
> least until the major TC version after the default switched to NIO.

We need a AJP-NIO connector first ;). Maybe an exercise for the upcoming
Apache Retreat?

The one huge advantage of AJP-NIO would be no need for aligning thread
counts on httpd and Tomcat or messing about with timeouts etc to ensure
connections <= maxThreads. As long as the *active* connections from
httpd <= maxThreads, all would be fine.

>> Solution B
>> ----------
>> Return to the Tomcat 6 implementation where maxConnections == maxThreads.
>>
>> Additional clean-up
>> -------------------
>> maxConnections is unnecessary in APR since pollerSize performs the same
>> function.
>>
>> Summary
>> -------
>> The proposed changes are:
>> a) restore disabling keep-alive when threads used>= 75% of maxThreads
>> b) remove maxConnections and associated code from the APR connector
>> c) remove the configuration options for maxConnections from the BIO
>> connector
>> d) use maxThreads instead of maxConnections for the BIO connector
>> e) update the docs
> 
> I agree (especially after your additional clarifications in reply to
> Konstantin).

Great. I think we are heading towards a consensus.

Mark


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