gentlemen, not sure if you had a chance to look this over, but it is
pretty interesting,
after some very basic tests, I get the NIO connector to perform better
than the blocking io connector
the peak data throughput are
NIO - 36,000KB/s
JIO - 35,000KB/s
APR - 24,000KB/s
basic connector config, with maxThreads=150,
./ab -n 500000 -c 100 -k -C
"test=89012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890"
http://localhost:8080/tomcat.gif
of course, not an all encapsulating test, but the NIO connector used to
always lag behind the JIO connector, in these simple tests. So lets
ignore the numbers, they aren't important.
Even though the APR connector does blocking read,the same optimization
can be implemented, just reverse the logic.
In the NIO connector if a read returns 0, it puts the socket back into
the poller. With APR, that same read would block until data was
available, but it can still be done.
When APR wakes up from the poller, we know there is data, if we run out
of data during the parsing of the request (request line+headers) don't
issue the 2nd read, just register the socket back with the poller.
chances are that if you ran out of data while parsing the request, you
will be waiting for more data on the line.
And because the NIO code is almost copy/paste from the APR code, porting
this optimization should be fairly straight forward.
As always, I could be wrong and it would have the reverse effect :) but
with keepalive connections, the optimization idea is pretty good.
Filip
[EMAIL PROTECTED] wrote:
Author: fhanik
Date: Wed Oct 18 16:24:52 2006
New Revision: 465417
URL: http://svn.apache.org/viewvc?view=rev&rev=465417
Log:
Implement non blocking read on HTTP requests.
A common scalability problem when it comes to HTTP is the fact that there are
slow clients, that will block a server resources while sending a HTTP request.
Especially when you have larger request headers.
On FreeBSD the kernel has a built in http filter to not wake up the application
socket handle until the entire request has been received, however on other
platforms this is not available.
With the Tomcat connectors, there is an obvious problem when it comes to slow
clients, if the client sends up a partial request, Tomcat will block the thread
until the client has finished sending the request. For example, if the client
has 10 headers it sends up the first 5 headers, then the next 5 in a sequential
batch, the tomcat thread is locked in a blocking read
I've tried to fix that problem by making the NIO connector be non blocking. The
only time the NIO connector will block now is when the servlet asks for data,
usually the request body, as we don't have a way to suspend a thread, like
continuations.
Once we have continuations(that can truly remember thread stack data), we can
have a truly non blocking server, but we are not there yet.
I believe this code could be easily ported to APR connector with very little
effort.
When you review this code, please note that I have not attemtped to rewrite the
header parse logic, I might do that in a later stage as this got a little
messy, but I wanted the proof of concept done first and reuse as much code as
possible.
Please feel free to review and even flame me if needed, at least that means
this got some attention :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
