tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: svn commit: r465417 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11:
Date Tue, 24 Oct 2006 14:33:42 GMT
I've been tracking down the phantom behavior on the NIO connector and 
found some results
1. Busy write, when the client is not reading fast enough ends up 
spinning the CPU, this is fixed
2. GC, the NIO connector generates a lot more garbage than I would like 
for it to, both JIO and APR have very low GC frequencies

On larger files, I get much better results with APR and JIO, probably 
explained to the fact that there really is no good way to do a blocking 
write using NIO.
I only get better results with NIO if the entire response can be sent 
down in one shot, meaning it will fit in the socket buffer.

I get occasional phantom slow downs with APR as well, not sure where 
they come from, I might dig into this after

So I'm gonna work some on the GC stuff for the NIO, should get it a 
little bit better.

thanks for testing along, and keeping me alert

Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>>> 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.
>> I am very skeptical about that trick.
> on most OS:es, there are kernel optimizations, I believe both linux 
> and windows have 1-st byte accept, meaning they wont send you the 
> accept signal until the first byte has arrived, and freebsd has a 
> complete httpfilter in their kernel, meaning the process wont even get 
> the socket until the entire http request is loaded up.
> this is awesome when you turn off keepalive,
> when keepalive is turned on, I believe this trick can be fairly 
> httpd, I think you can achieve the same thing using 
> mpm_event, where the http request doesn't get dispatched until it is 
> received on the server.
>> As usual, in case someone is still interested, I get opposite results 
>> on my toy O$, 
> cool, I've not yet ran on windows.
>> with the result being APR > JIO > NIO although all three are fast 
>> enough (unfortunately, I did not try the before/after to see if the 
>> trick did something for me). I also do get a dose of paranormal 
>> activity using the NIO connector.
> I do see the phantom behavior every once in a while on FC5 with JDK 
> 1.5.0_07 as well.
> I'm suspecting it has to do with two JDK bugs that I am bypassing 
> right now, I'm gonna run some more tests, to see if I can isolate it.
> in longer test runs it clears itself up pretty guick.
>                try {
>                    wakeupCounter.set(0);
>                    keyCount =;
>                } catch ( NullPointerException x ) {
>                    //sun bug 5076772 on windows JDK 1.5
>                    if ( wakeupCounter == null || selector == null ) 
> throw x;
>                    continue;
>                } catch ( CancelledKeyException x ) {
>                    //sun bug 5076772 on windows JDK 1.5
>                    if ( wakeupCounter == null || selector == null ) 
> throw x;
>                    continue;
>                } catch (Throwable x) {
>                    log.error("",x);
>                    continue;
>                }
> currently also, its doing a busy write, need to fix this as for slow 
> clients it affects CPU usage.
>> BTW, I don't know if you know about it, but the APR and JIO AJP that 
>> are in o.a.coyote.ajp should both be faster than the classic o.a.jk. 
>> Of course, it's not that hard, since the connector is much simpler 
>> (and just does basic AJP).
> no, I didn't know, but its very useful stuff.
> thanks
> Filip
>> Rémy
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message