hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <e...@tibco.com>
Subject Re: [HttpCommon] NIO is one huge disappointment
Date Wed, 17 Aug 2005 20:10:11 GMT

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 

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.


Oleg Kalnichevski wrote:

>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:
>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.
>[1] Dell Dimension 8300, Pentium 4 3.00GHz, 512MB, Fedora Core 4,
>[2] A pile of old trash running Windows XP Home SP2 (rather badly)
>To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

View raw message