Hi Mladen,
On 07/20/2012 08:59 PM, Mladen Adamovic wrote:
>> Hmm, it's probably terminology problem again. When request comes on a
>> connection we put connection to a queue to process its request.
>> So number of time connection was queued is more or less equivalent to a
>> number HTTP requests processed (it might not be true for HTTP pipelined
>> requests).
> Hm, so if some bots are using keep-alive connections, than if there is
> only 5 threads processing requests, they might be busy processing
> keep-alive bots and visitors might have to wait.
Most of the time (if HTTP pipelining is not used) connection is getting
queued to process just one request, then we dequeue the connection and
processing next queued connection.
So thread-pool is not stuck w/ keep-alive requests that come from one
connection.
> That's why I think raising default number of threads for
> httpthreadpool to Max Thread Pool Size: 400
> I think default server config needs to raise this value, assuming that
> 512 connections server can handle, if I'm correct.
Perf. tests we did show that 5 threads can handle thousands of
connections for simple webapps, for sure if you have a servlet, which
makes DB requests (which may take longer time) - you have to increase
the thread-pool size.
WBR,
Alexey.