tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Tomcat does not honor acceptCount configuration variable
Date Sat, 08 May 2010 12:30:55 GMT
Timir Hazarika wrote:
>>
>> This is not an accept problem, this is a problem with having serviced a
> 
> request via a socket and then closing the connection. Given that you
> 
> can't avoid accepting connections on a useful web server, you will not
> 
> be able to prevent them from going through their natural lifecycle.
> 
> 
> Chris,
> 
> Thanks. I finally chose to write my own endpoint/HTTP protocol handler to
> better address the use case of immediate connection reset under load
> conditions. The acceptor logic in custom code simply closes socket when
> there's no free worker available.
> 
> You'll notice in current implementation of tomcat JIOEndpoint, that the
> acceptor thread waits for a free worker thread instead.
> 

I guess I do not understand what your custom code achieves, as compared 
to just setting the acceptCount attribute to 1 or so.

Suppose one request takes approximately 3 s to process.

Suppose that at time T0, you have 100 worker threads available to 
process requests.
Starting at time T0, 110 requests (R001-R110) arrive, inside a 3-second 
period.
The first 100 (R001-R100) will get a free worker.
The next 10 (R101-R110) will be rejected, since there is no free worker.
At time T0 + 3.02s, the worker who got the first request R001 finishes, 
and becomes available.
At time T0 + 3.03s, a new request R111 comes in.
It will find an available worker and will be processed.
So, requests R101-R110 which came in first are rejected, but request 
R111 which came in much later is accepted.

Suppose instead we have the normal scheme, with an accept queue length 
of 100 (acceptCount="100").

Suppose that at time T0, you have 100 worker threads available to 
process requests.
Starting at time T0, 110 requests (R001-R110) arrive, inside of a 
3-second period.
The first 100 (R001-R100) will get a free worker, and start being 
processed right away.
The next 10 (R101-R110) will be queued, since there is no free worker.
At time T0 + 3.02s, the worker who got the first request R001 finishes, 
and becomes available.
Request R101 is now accepted, and starts being processed.
At time T0 + 3.03s, a new request R111 comes in.
There is no available worker, so it will be queued, behind R110.
As soon as workers becomes available, R102-R111 will be processed, in 
the order in which they came in.
It is only if the accept queue gets to be totally full (with 100 
requests being processed, and 100 waiting), that subsequent requests 
would start to be discarded.

The socket accept queue is basically a "shock absorber".  It allows a 
temporary surge in requests to be absorbed, while workers are 
temporarily overloaded.  As soon as some capacity is available, the 
first request in that queue will be accepted and processed. Then the 
next one..  By increasing/decreasing the acceptCount, you determine how 
big your shock absorber is, without using up too many resources.

With your scheme, you are just transforming this shock absorber into a 
rigid closed door, equivalent to setting acceptCount to 1.  And you are 
allowing some requests to "jump the queue" compared to others.

Or did I miss something ?




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


Mime
View raw message