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)
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.
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.
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 <[EMAIL PROTECTED]> 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: [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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
[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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
