hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpCommon] NIO is one huge disappointment
Date Wed, 17 Aug 2005 21:40:53 GMT
Eric, it might well be the screwy setup of my box. Nonetheless, even the
numbers that you have got show that old IO still outperforms NIO by
quite a margin:

JDK 1.5.0_04-b05: Old IO 179 vs NIO w/ Select 210

We are still talking ~15% performance difference, which should not be
taken lightly. Actually this is consistent with what I see when running
the test on the WinXP machine

Oleg

On Wed, 2005-08-17 at 13:10 -0700, Eric Johnson wrote:
> 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: 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
> 
> 


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


Mime
View raw message