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: [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]
