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 Thu, 18 Aug 2005 08:18:35 GMT
On Thu, Aug 18, 2005 at 10:04:56AM +0200, Ortwin Gl?ck wrote:
> Here are my numbers on a Win XP Pro, Pentium M 1.6 GHz, Sun JDK 1.4.2_08:
> 
> Old IO average time (ms): 3
> java.nio.channels.ClosedByInterruptException
> 	at 
> java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:184)
> 	at 
> sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:141)
> 	at 
> 	tests.performance.NIOvsOldIO$NIOListenerThread.run(NIOvsOldIO.java:239)
> Blocking NIO average time (ms): 1
> java.nio.channels.ClosedByInterruptException
> 	at 
> java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:184)
> 	at 
> sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:141)

Odi,

(1) Please take a closer look at the exception stack trace. The exception
is thrown when the server socket gets interrupted while blocked in the
listen method. This exception is perfectly legitimate in this context


> 	at 
> 	tests.performance.NIOvsOldIO$NIOListenerThread.run(NIOvsOldIO.java:239)
> NIO with Select average time (ms): 12
> 
> 
> First I see exceptions - not so good. Then my numbers are much smaller. 
> And NIO appears really slow.
> 
> But I also see flaws in the test code:
> 
>             long start = System.currentTimeMillis();
>             while (in.read(tmp) != -1) {
>             }
>             long t = System.currentTimeMillis() - start;
> 
> Given the rather large jitter of System.currentTimeMillis() of about 
> 15ms, in this case t is almost always 0 and sometimes 15. This does not 
> test the time it takes to read but it tests the jitter of the clock. A 
> similar argument holds true for the NIOSelectReceiver, where we 
> apparently get more 15 than 0.
> 

(2) This should not really require a PhD Stanford to figure out that if
you hardware is faster that the one I used to run the test you might
want to tweak the parameters a little in order to make the numbers a
little more representative. Please increase the buffer size and retest


> Just insert System.out.println(t) into the synchronized block and see 
> for yourself.
> 
> This test apparently does not make any real statements about the 
> performance of NIO vs old IO. Sorry, Oleg, you will have to look into it 
> again.

Feel free to modify it to make it more meaningful. The source is there

Oleg

> 
> Odi
> 
> Michael Becke wrote:
> >Here are my numbers, just for comparison:
> >
> >Windows XP - 3.2GHz 1GB - Dell OptiPlex
> >
> >JDK 1.5.0_02
> >Old IO average time (ms): 17
> >Blocking NIO average time (ms): 16
> >NIO with Select average time (ms): 19
> >
> >JDK 1.4.2_05
> >Old IO average time (ms): 17
> >java.nio.channels.ClosedByInterruptException
> >Blocking NIO average time (ms): 18
> >NIO with Select average time (ms): 20
> >
> >Running on linux (quite an old machine)  took so long that I just 
> >cancelled it.
> >
> >Mike
> >
> >On 8/17/05, Oleg Kalnichevski <olegk@apache.org> wrote:
> >
> >>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
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> >
> >
> 
> -- 
> [web]  http://www.odi.ch/
> [blog] http://www.odi.ch/weblog/
> [pgp]  key 0x81CF3416
>        finger print F2B1 B21F F056 D53E 5D79  A5AF 02BE 70F5 81CF 3416
> 
> ---------------------------------------------------------------------
> 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