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
useful.in 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 = selector.select(selectorTimeout);
} 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
