Oleg,
Odd - I see different results.
JDK 1.4.2_08-b03:
Old IO average time (ms): 737
Blocking NIO average time (ms): 194
NIO with Select average time (ms): 208
JDK 1.5.0_04-b05 (I compiled against JDK 1.4, and didn't recompile for
this test):
Old IO average time (ms): 179
Blocking NIO average time (ms): 159
NIO with Select average time (ms): 210
I just grabbed your code, compiled it, and ran it.
I'm running IBM T40 laptop, 1.6GHz processor, Gentoo Linux with kernel
2.6.12-r6.
I find it fascinating that JDK 1.5 so dramatically speeds up the old IO,
and slightly improves the blocking NIO, but has no effect on the
"select" scenario.
By the way - THANKS for putting together the test.
-Eric.
Oleg Kalnichevski wrote:
Folks,
I have spend past several miserable nights analyzing the performance of
the new Coyote HTTP connector. I have discovered that HttpCommon code
was horribly slow for larger request/response bodies, especially
chunk-encoded, on my Linux box [1], whereas it seemed almost fine on a
much slower WinXP laptop of my wife [2]. To cut a long and sad story
short, after some investigations I found out that the culprit was NIO.
The way I see it, NIO, as presently implemented in Sun's JREs for Linux,
simply sucks. Actually blocking NIO appears more or less okay. The real
problem is the NIO channel selector, which proves horribly expensive in
terms of performance (we DO have to use a selector on the socket
channel, because it is the only way (I know of) to implement socket
timeout with NIO).
I have written a small test app to demonstrate the problem:
http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/http-common/src/test/tests/performance/NIOvsOldIO.java
This is what I get on my Linux box
=========================================
Old IO average time (ms): 1274
Blocking NIO average time (ms): 1364
NIO with Select average time (ms): 4981
=========================================
Bottom line: NIO may still be a better model for some special cases such
as instant messaging where one can have thousands of mostly idle
connections with fairly small and infrequent data packets. At the same
time, I have come to a conclusion that NIO makes no sense of what so
ever for synchronous HTTP (servlets, for instance), where large
request/response entities need to be consumed/produced using
InputStream/OutputStream interfaces, data tends to come in steady
streams of chunks, and connections are relatively short-lived.
I intent to remove all the NIO related class from HttpCommon and put
them in the HttpAsynch module, where they may serve as a starting point
for the asynchronous HTTP implementation. Please take a look at the test
app and complain loudly if you think something is wrong. Otherwise I'll
go ahead and get rid of NIO code in HttpCommon.
Oleg
===
[1] Dell Dimension 8300, Pentium 4 3.00GHz, 512MB, Fedora Core 4,
2.6.11-1.1369_FC4smp
[2] A pile of old trash running Windows XP Home SP2 (rather badly)
---------------------------------------------------------------------
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]
