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
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
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
