tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: svn commit: r465417 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11: Http11NioProcessor.java InternalNioInputBuffer.java
Date Thu, 19 Oct 2006 22:24:53 GMT
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

fhanik@apache.org 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message