tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: BIO performance issues
Date Wed, 04 May 2011 16:33:39 GMT
On 5/4/2011 9:54 AM, Mark Thomas wrote:
> On 04/05/2011 16:17, Filip Hanik - Dev Lists wrote:
>> On 5/3/2011 2:02 PM, Mark Thomas wrote:
>> In a similar fashion, we can also craft a test run that will yield a
>> substantial improvement over the old implementation in throughput.
>> So there is a test case to prove every scenario.
> Could you outline what a test case looks like. It would help with the
> general understanding of what problem maxConnections is trying to solve.

ok, we have an acceptor thread(AT) that does ServerSocket.accept() in an endless loop.
In the previous implementation, the AT would accept the socket, then wait for a thread to
become available to handle the connection.
New incoming connections would then be handled by the backlog in the operating system. The
old implementation was extremely unfair in how it 
handled the requests, some requests could get handled right away, while others could wait
for long period of times (this is with the old 
impl). As you may be familiar, a client's connection may "die" in the backlog at which point
the client has to attempt a new connection.

if you really want a simple test case, then do

In the old impl, keep alive would be turned off and performance would suffer, even though
the system has plenty of resources to handle it. 
while this test case is very narrow and simple, it's the other extreme of the use case you

The new implementation, queue based, was as a result to be able to disconnect a thread from
a socket due to the new async requirements. 
Previously, a thread was married to a socket for as long as the socket was alive.

Anyway, with the new implementation, just like with NIO, there is no longer a stopper on the
acceptor thread (AT) it will happily keep 
accepting connections until you run out of buffer space or port numbers.
This presents a DoS risk, this risk has existed in NIO for a while. So maxConnections has
been put in place to stop accepting connections, 
and push back new connections into the backlog.

so maxConnections exists to stop the acceptor thread from taking in more than it can handle.

>> Here is what I propose, and you'll see that it's pretty much inline with
>> what you suggest.
> Yep. That works for me. I do have some additional questions around
> maxConnections - mainly so I can get the docs right.
>>> c) remove the configuration options for maxConnections from the BIO
>>> connector
>> I think you still misunderstand why maxConnections is there, at some
>> point you need to push back on the TCP stack.
> Some more detail on exactly the purpose of maxConnections would be
> useful. The purposes I can see are:
> - limiting connections since the addition of the queue means they are
> not limited by maxThreads
correct, a system with
maxThreads=200 should be able to handle connections=500 with keep alive on and perform very

> - fair (order received) processing of connections?
correct. almost no clients use pipelined requests, so chances that there is data on a new
finished request is very slim. It is more probable 
that there is data on a request that was finished earlier in the cycle.

I hope that explains it. And by default, with the config options/defaults I suggested, you'll
get the exact behavior of the old connector, 
but can still benefit from the new connector logic
> - ?
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> -----
> No virus found in this message.
> Checked by AVG -
> Version: 10.0.1321 / Virus Database: 1500/3615 - Release Date: 05/04/11

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

View raw message