tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: BIO performance issues
Date Wed, 04 May 2011 11:50:23 GMT
On 04/05/2011 12:04, Konstantin Kolinko wrote:
> I do not quite get what happens in 6s. My first understanding from
> reading the scenario was that the threads at 2s are busy because we
> need them to process keep-alive connections. Then I see that at 6s
> keep-alive connections are in the Queue.
> What prevents those connections that exist at "2s" from being placed
> in the Queue?

The keep-alive state is as viewed by the client. At 6s the requests in
the queue are open connections that have already processed one requests
and therefore are in HTTP keep-alive. However, there are no free threads
to process them. If any data was to turn up on those connections they
would sit in the queue until a thread was available.

The difference between "Allocated threads. In HTTP keep-alive Xs" and
"Queued. In HTTP keep-alive for Xs" is that in the allocated case, data
will be processed as soon as it arrives. In the queued case, data will
not be processed a) all the connections ahead of it in the queue have
been processed and b) a thread is available to process it.

> What is "simulated polling" that you tried to implement? Was it trying
> to read data from each of keep-alive sockets in turn with a short
> timeout?

> Where increased CPU usage comes from?
Because of the short timeout, threads that would normally be blocked are
generating SocketTimeoutExceptions and looping through the
Http11Processor.process method every 100ms.

>> The proposed changes are:
>> a) restore disabling keep-alive when threads used >= 75% of maxThreads
> Anyway, if the problem persists, I'll be +1 for a), as it should
> prevent us from falling in this state.

That certainly would deal with the immediate issue. I didn't fully
understand Filip's changes when I removed the code that disabled keep-alive.

> +0 for b)..e), as I do not quite get them. An alternative could be to
> change the default value of maxConnections and calculate it from
> maxThreads.

With the change described in a), maxConnections is effectively an
duplication of acceptCount for BIO. Changes c) and d) are intended to
remove the duplication so acceptCount functions as it does in Tomcat 6.

maxConnections duplicates pollerSize for APR. Change b) is intended to
remove the duplication.

Change e) will align the docs with whatever changes are made. Currently
maxConnections is documented as only applying to BIO whereas it applies
to BIO, NIO and APR.

> I wonder, maybe it is time to use the NIO connector as the default one
> in Tomcat 7.

I was beginning to think the along the same lines although I was
actually thinking remove BIO entirely for Tomcat 8.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message