Scott Marlow wrote:
Hi, I wonder if anyone has any feedback on a performance change that I am working on making.
Can you compare the performance of you code with the standard implementation when the concurrency is lower then maxThreads value?
I see no point to make patches that will deal with cases presuming that the concurrency is always higher then the actual number of worker threads available.
IMHO this is a bad design approach for the http applications, and NIO performance is a proof of that. It might help in cases where you have a very very slow clients. In any other case the thread context switching will kill the performance thought.
Further more I don't see how can you avoid keep-alive connection problems without using a thread-per-connection model. The point is that with 100 keep-alive connections you will still have 100 busy threads.
Why ? 100 keep alive connections doesn't mean 100 active requests, in real servers there are many 'keep alive' connections that are just waiting for the next request.
In all servers I know, concurrency was higher than the configured number of workers - at peak time, at least, where performance matters.
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
