You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2005/08/17 21:48:47 UTC
[HttpCommon] NIO is one huge disappointment
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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Sam Berlin <sb...@gmail.com>.
> We'll certainly use NIO for the HttpAsynch stuff, but at this point I
> see NIO as completely useless for APIs that make use of InputStream /
> OutputStream interfaces
Unfortunately, you're correct. I wouldn't really recommend using NIO
in blocking mode, either, as there's an inordinate amount of bugs &
rather slow processing overall. From what I've seen, NIO is really
only useful if you have a truly asynchronous architecture, which is
not possible if you need to fit in the prescribed servlet API.
It is possible to convert a non-blocking channel into a blocking
stream using Pipes (though I don't recommend it, because they have
their own problems) or a home-brewn locking/waiting (as in the two
classes at http://limewire.org/fisheye/viewrep/limecvs/core/com/limegroup/gnutella/io/BufferInputStream.java?r=1.8
& http://limewire.org/fisheye/viewrep/limecvs/core/com/limegroup/gnutella/io/NIOInputStream.java?r=1.9
), but to be honest, it's really not necessary if all you're going to
end up doing is blocking transfers anyway.
NIO is best when the application (or significant parts of it) is
non-blocking and single-threaded. There's really no reason to use it
otherwise.
Thanks,
Sam
>
> Oleg
>
> On Wed, 2005-08-17 at 17:06 -0400, Sam Berlin wrote:
> > Hi Oleg,
> >
> > While it may not make a difference, one important thing with using the
> > NIO package in non-blocking mode is to read as much as possible from
> > the channel during a single select. That is, in the
> > NIOSelectReceiever.process method, the part that currently is:
> >
> > for (;;) {
> > selector.select(SO_TIMEOUT);
> > int l = channel.read(tmp);
> > if (l == -1) {
> > break;
> > }
> > tmp.clear();
> > }
> >
> > should be:
> >
> > for (;;) {
> > selector.select(SO_TIMEOUT);
> > int l = channel.read(tmp);
> > while( l > 0 ) {
> > // process data.
> > tmp.clear();
> > l = channel.read(tmp);
> > }
> >
> > if (l == -1) {
> > break;
> > }
> >
> > tmp.clear();
> > }
> >
> > This ensures that as much data as is on the Socket/Channel can be
> > processed in a single statement without incurring the wrath of
> > multiple selects.
> >
> > Thanks,
> > Sam
> >
> >
> > On 8/17/05, Oleg Kalnichevski <ol...@apache.org> 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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Oleg Kalnichevski <ol...@apache.org>.
Sam,
Unfortunately this does not make a difference in this case, as the data
is not meant to be processed inside the loop. Ultimately the data needs
to be made available to the servlet via InputStream interface, where
data processing is meant to take place.
> for (;;) {
> selector.select(SO_TIMEOUT);
> int l = channel.read(tmp);
> while( l > 0 ) {
> // process data.
> tmp.clear();
Data cannot be processed / consumed at this point
> l = channel.read(tmp);
> }
We'll certainly use NIO for the HttpAsynch stuff, but at this point I
see NIO as completely useless for APIs that make use of InputStream /
OutputStream interfaces
Oleg
On Wed, 2005-08-17 at 17:06 -0400, Sam Berlin wrote:
> Hi Oleg,
>
> While it may not make a difference, one important thing with using the
> NIO package in non-blocking mode is to read as much as possible from
> the channel during a single select. That is, in the
> NIOSelectReceiever.process method, the part that currently is:
>
> for (;;) {
> selector.select(SO_TIMEOUT);
> int l = channel.read(tmp);
> if (l == -1) {
> break;
> }
> tmp.clear();
> }
>
> should be:
>
> for (;;) {
> selector.select(SO_TIMEOUT);
> int l = channel.read(tmp);
> while( l > 0 ) {
> // process data.
> tmp.clear();
> l = channel.read(tmp);
> }
>
> if (l == -1) {
> break;
> }
>
> tmp.clear();
> }
>
> This ensures that as much data as is on the Socket/Channel can be
> processed in a single statement without incurring the wrath of
> multiple selects.
>
> Thanks,
> Sam
>
>
> On 8/17/05, Oleg Kalnichevski <ol...@apache.org> 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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Sam Berlin <sb...@gmail.com>.
Hi Oleg,
While it may not make a difference, one important thing with using the
NIO package in non-blocking mode is to read as much as possible from
the channel during a single select. That is, in the
NIOSelectReceiever.process method, the part that currently is:
for (;;) {
selector.select(SO_TIMEOUT);
int l = channel.read(tmp);
if (l == -1) {
break;
}
tmp.clear();
}
should be:
for (;;) {
selector.select(SO_TIMEOUT);
int l = channel.read(tmp);
while( l > 0 ) {
// process data.
tmp.clear();
l = channel.read(tmp);
}
if (l == -1) {
break;
}
tmp.clear();
}
This ensures that as much data as is on the Socket/Channel can be
processed in a single statement without incurring the wrath of
multiple selects.
Thanks,
Sam
On 8/17/05, Oleg Kalnichevski <ol...@apache.org> 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
Re: [HttpCommon] NIO is one huge disappointment (maybe not)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, Aug 19, 2005 at 04:21:29PM +0200, Roland Weber wrote:
> Hi Michael,
>
> > Bytes written: 200,482,200
> > Calls to writeToChannel: 1,126,198
> > Bytes written per call: ~178
> >
> > This seems pretty fishy to me considering that the buffer is 4096
> > bytes. My knowledge of NIO is quite limited so I don't have much to
> > compare these numbers to. Any ideas?
>
> One guess out of the blue: auto-flush after each header line?
>
> cheers,
> Roland
>
That would have been just way too easy.
This is how a 10000 bytes POST gets chunked:
221
8192
8192
8192
8192
8192
8192
8192
8192
8192
8192
8192
8192
1696
Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
Average (nanosec): 146,754,126
Looks sane to me: request line + headers in one chunk, the body chunks
perfectly fit one IP frame. This should have been blasingly fast
Oleg
>
>
> ---------------------------------------------------------------------
> 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
Re: [HttpCommon] NIO is one huge disappointment (maybe not)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, Aug 19, 2005 at 10:18:54AM -0400, Michael Becke wrote:
> As your numbers and some tests I've been trying show it seems that the
> write performance is the key area of difficultly. From some
> "profiling" I've been doing it looks like writeToChannel() is called
> an extremely large number of times, especially when you considering
> that the entity is quite large and already buffered to memory. For
> example I ran just the post request 200 times and here are some
> numbers I get:
>
> Bytes written: 200,482,200
> Calls to writeToChannel: 1,126,198
> Bytes written per call: ~178
>
> This seems pretty fishy to me considering that the buffer is 4096
> bytes. My knowledge of NIO is quite limited so I don't have much to
> compare these numbers to. Any ideas?
Mike,
I'll be looking into it. At least we have identified the bottleneck
Apparently there's something really wrong with the ChunkedInputStream as
well. This is another problem area that needs to be investigated
Oleg
>
> Mike
>
> On 8/18/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > Folks,
> >
> > Well, looks like things are slightly more complicated than I initially
> > asserted. I just could not let this one rest and kept on experimenting.
> > As soon as I stopped just stupidly pumping lots of data through the
> > socket and started using real HTTP requests things started looking quite
> > differently. NIO still sucks when it comes to sending and receiving
> > large content bodies (~ 1MB), but it tends to perform much better for
> > smaller messages (1KB -100KB). It appears the HTTP data receiver based
> > on NIO can indeed parse HTTP headers much faster as I hoped.
> >
> > Here's the test app I have been using
> > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/tests/performance/PerformanceTest.java
> >
> > In order to run it one needs the latest SVN snapshot of HttpCommon [1]
> > and a reasonably recent version of Tomcat, preferably 5.5 branch. This
> > is the server.xml that I have been using [2]. (Please do not forget to
> > comment out the other connector on port 8888)
> >
> > These are my numbers
> >
> > Windows XP, P4, 1GB
> >
> > tests.performance.PerformanceTest 8080 200 NIO
> > ==============================================
> > Request: GET /tomcat-docs/changelog.html HTTP/1.1
> > Average (nanosec): 17,832,699
> > Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > Average (nanosec): 3,444,763
> > Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > Average (nanosec): 49,411,834
> >
> > tests.performance.PerformanceTest 8080 200 OldIO
> > ==============================================
> > Request: GET /tomcat-docs/changelog.html HTTP/1.1
> > Average (nanosec): 24,436,939
> > Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > Average (nanosec): 15,563,380
> > Request failed: java.nio.channels.ClosedChannelException
> > Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > Average (nanosec): 26,104,509
> >
> > Oleg
> >
> > [1]
> > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/http-common/
> > [2]
> > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/server.xml
> >
> > On Wed, 2005-08-17 at 21:48 +0200, 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
Re: [HttpCommon] NIO is one huge disappointment (maybe not)
Posted by Sam Berlin <sb...@gmail.com>.
While it may not be design you're ultimately looking for, I do
recommend taking a look at the 'io' package at
http://limewire.org/fisheye/viewrep/limecvs/core/com/limegroup/gnutella/io
. It may help with fleshing out the design necessary for HttpClient.
Thanks,
Sam
On 8/19/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2005-08-19 at 18:17 +0200, Oleg Kalnichevski wrote:
> > On Fri, Aug 19, 2005 at 10:18:54AM -0400, Michael Becke wrote:
> > > As your numbers and some tests I've been trying show it seems that the
> > > write performance is the key area of difficultly. From some
> > > "profiling" I've been doing it looks like writeToChannel() is called
> > > an extremely large number of times, especially when you considering
> > > that the entity is quite large and already buffered to memory. For
> > > example I ran just the post request 200 times and here are some
> > > numbers I get:
> > >
> > > Bytes written: 200,482,200
> > > Calls to writeToChannel: 1,126,198
> > > Bytes written per call: ~178
> > >
> > > This seems pretty fishy to me considering that the buffer is 4096
> > > bytes. My knowledge of NIO is quite limited so I don't have much to
> > > compare these numbers to. Any ideas?
> > >
> > > Mike
> > >
> >
> > Mike and Roland
> >
> > I found the culprit. An open read selector on a non-blocking channel
> > slows down write I/O by 100%. Go figure.
> >
> > I'll be working on a fix.
> >
>
> Mike et al,
>
> I looked at possibility of fixing the problem by registering and
> unregistering the socket channel for each read operation that requires a
> timeout. This approach unfortunately causes massive stability problems.
> Eventually the application goes down with a NullPointerException
> originating from one of the com.sun.io packages. This is a dead end.
>
> I think it is time we reevaluated the problem on the design level. I
> will send another email shortly describing what I personally see as the
> only way to salvage NIO for HttpCommon
>
> Oleg
>
>
> > Oleg
> >
> >
> > > On 8/18/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > > Folks,
> > > >
> > > > Well, looks like things are slightly more complicated than I initially
> > > > asserted. I just could not let this one rest and kept on experimenting.
> > > > As soon as I stopped just stupidly pumping lots of data through the
> > > > socket and started using real HTTP requests things started looking quite
> > > > differently. NIO still sucks when it comes to sending and receiving
> > > > large content bodies (~ 1MB), but it tends to perform much better for
> > > > smaller messages (1KB -100KB). It appears the HTTP data receiver based
> > > > on NIO can indeed parse HTTP headers much faster as I hoped.
> > > >
> > > > Here's the test app I have been using
> > > > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/tests/performance/PerformanceTest.java
> > > >
> > > > In order to run it one needs the latest SVN snapshot of HttpCommon [1]
> > > > and a reasonably recent version of Tomcat, preferably 5.5 branch. This
> > > > is the server.xml that I have been using [2]. (Please do not forget to
> > > > comment out the other connector on port 8888)
> > > >
> > > > These are my numbers
> > > >
> > > > Windows XP, P4, 1GB
> > > >
> > > > tests.performance.PerformanceTest 8080 200 NIO
> > > > ==============================================
> > > > Request: GET /tomcat-docs/changelog.html HTTP/1.1
> > > > Average (nanosec): 17,832,699
> > > > Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > > Average (nanosec): 3,444,763
> > > > Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > > Average (nanosec): 49,411,834
> > > >
> > > > tests.performance.PerformanceTest 8080 200 OldIO
> > > > ==============================================
> > > > Request: GET /tomcat-docs/changelog.html HTTP/1.1
> > > > Average (nanosec): 24,436,939
> > > > Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > > Average (nanosec): 15,563,380
> > > > Request failed: java.nio.channels.ClosedChannelException
> > > > Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > > Average (nanosec): 26,104,509
> > > >
> > > > Oleg
> > > >
> > > > [1]
> > > > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/http-common/
> > > > [2]
> > > > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/server.xml
> > > >
> > > > On Wed, 2005-08-17 at 21:48 +0200, 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
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [HttpCommon] NIO is one huge disappointment (maybe not)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2005-08-19 at 18:17 +0200, Oleg Kalnichevski wrote:
> On Fri, Aug 19, 2005 at 10:18:54AM -0400, Michael Becke wrote:
> > As your numbers and some tests I've been trying show it seems that the
> > write performance is the key area of difficultly. From some
> > "profiling" I've been doing it looks like writeToChannel() is called
> > an extremely large number of times, especially when you considering
> > that the entity is quite large and already buffered to memory. For
> > example I ran just the post request 200 times and here are some
> > numbers I get:
> >
> > Bytes written: 200,482,200
> > Calls to writeToChannel: 1,126,198
> > Bytes written per call: ~178
> >
> > This seems pretty fishy to me considering that the buffer is 4096
> > bytes. My knowledge of NIO is quite limited so I don't have much to
> > compare these numbers to. Any ideas?
> >
> > Mike
> >
>
> Mike and Roland
>
> I found the culprit. An open read selector on a non-blocking channel
> slows down write I/O by 100%. Go figure.
>
> I'll be working on a fix.
>
Mike et al,
I looked at possibility of fixing the problem by registering and
unregistering the socket channel for each read operation that requires a
timeout. This approach unfortunately causes massive stability problems.
Eventually the application goes down with a NullPointerException
originating from one of the com.sun.io packages. This is a dead end.
I think it is time we reevaluated the problem on the design level. I
will send another email shortly describing what I personally see as the
only way to salvage NIO for HttpCommon
Oleg
> Oleg
>
>
> > On 8/18/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > Folks,
> > >
> > > Well, looks like things are slightly more complicated than I initially
> > > asserted. I just could not let this one rest and kept on experimenting.
> > > As soon as I stopped just stupidly pumping lots of data through the
> > > socket and started using real HTTP requests things started looking quite
> > > differently. NIO still sucks when it comes to sending and receiving
> > > large content bodies (~ 1MB), but it tends to perform much better for
> > > smaller messages (1KB -100KB). It appears the HTTP data receiver based
> > > on NIO can indeed parse HTTP headers much faster as I hoped.
> > >
> > > Here's the test app I have been using
> > > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/tests/performance/PerformanceTest.java
> > >
> > > In order to run it one needs the latest SVN snapshot of HttpCommon [1]
> > > and a reasonably recent version of Tomcat, preferably 5.5 branch. This
> > > is the server.xml that I have been using [2]. (Please do not forget to
> > > comment out the other connector on port 8888)
> > >
> > > These are my numbers
> > >
> > > Windows XP, P4, 1GB
> > >
> > > tests.performance.PerformanceTest 8080 200 NIO
> > > ==============================================
> > > Request: GET /tomcat-docs/changelog.html HTTP/1.1
> > > Average (nanosec): 17,832,699
> > > Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > Average (nanosec): 3,444,763
> > > Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > Average (nanosec): 49,411,834
> > >
> > > tests.performance.PerformanceTest 8080 200 OldIO
> > > ==============================================
> > > Request: GET /tomcat-docs/changelog.html HTTP/1.1
> > > Average (nanosec): 24,436,939
> > > Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > Average (nanosec): 15,563,380
> > > Request failed: java.nio.channels.ClosedChannelException
> > > Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > Average (nanosec): 26,104,509
> > >
> > > Oleg
> > >
> > > [1]
> > > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/http-common/
> > > [2]
> > > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/server.xml
> > >
> > > On Wed, 2005-08-17 at 21:48 +0200, 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpCommon] NIO is one huge disappointment (maybe not)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, Aug 19, 2005 at 10:18:54AM -0400, Michael Becke wrote:
> As your numbers and some tests I've been trying show it seems that the
> write performance is the key area of difficultly. From some
> "profiling" I've been doing it looks like writeToChannel() is called
> an extremely large number of times, especially when you considering
> that the entity is quite large and already buffered to memory. For
> example I ran just the post request 200 times and here are some
> numbers I get:
>
> Bytes written: 200,482,200
> Calls to writeToChannel: 1,126,198
> Bytes written per call: ~178
>
> This seems pretty fishy to me considering that the buffer is 4096
> bytes. My knowledge of NIO is quite limited so I don't have much to
> compare these numbers to. Any ideas?
>
> Mike
>
Mike and Roland
I found the culprit. An open read selector on a non-blocking channel
slows down write I/O by 100%. Go figure.
I'll be working on a fix.
Oleg
> On 8/18/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > Folks,
> >
> > Well, looks like things are slightly more complicated than I initially
> > asserted. I just could not let this one rest and kept on experimenting.
> > As soon as I stopped just stupidly pumping lots of data through the
> > socket and started using real HTTP requests things started looking quite
> > differently. NIO still sucks when it comes to sending and receiving
> > large content bodies (~ 1MB), but it tends to perform much better for
> > smaller messages (1KB -100KB). It appears the HTTP data receiver based
> > on NIO can indeed parse HTTP headers much faster as I hoped.
> >
> > Here's the test app I have been using
> > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/tests/performance/PerformanceTest.java
> >
> > In order to run it one needs the latest SVN snapshot of HttpCommon [1]
> > and a reasonably recent version of Tomcat, preferably 5.5 branch. This
> > is the server.xml that I have been using [2]. (Please do not forget to
> > comment out the other connector on port 8888)
> >
> > These are my numbers
> >
> > Windows XP, P4, 1GB
> >
> > tests.performance.PerformanceTest 8080 200 NIO
> > ==============================================
> > Request: GET /tomcat-docs/changelog.html HTTP/1.1
> > Average (nanosec): 17,832,699
> > Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > Average (nanosec): 3,444,763
> > Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > Average (nanosec): 49,411,834
> >
> > tests.performance.PerformanceTest 8080 200 OldIO
> > ==============================================
> > Request: GET /tomcat-docs/changelog.html HTTP/1.1
> > Average (nanosec): 24,436,939
> > Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > Average (nanosec): 15,563,380
> > Request failed: java.nio.channels.ClosedChannelException
> > Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > Average (nanosec): 26,104,509
> >
> > Oleg
> >
> > [1]
> > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/http-common/
> > [2]
> > http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/server.xml
> >
> > On Wed, 2005-08-17 at 21:48 +0200, 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
Re: [HttpCommon] NIO is one huge disappointment (maybe not)
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Michael,
> Bytes written: 200,482,200
> Calls to writeToChannel: 1,126,198
> Bytes written per call: ~178
>
> This seems pretty fishy to me considering that the buffer is 4096
> bytes. My knowledge of NIO is quite limited so I don't have much to
> compare these numbers to. Any ideas?
One guess out of the blue: auto-flush after each header line?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpCommon] NIO is one huge disappointment (maybe not)
Posted by Michael Becke <mb...@gmail.com>.
As your numbers and some tests I've been trying show it seems that the
write performance is the key area of difficultly. From some
"profiling" I've been doing it looks like writeToChannel() is called
an extremely large number of times, especially when you considering
that the entity is quite large and already buffered to memory. For
example I ran just the post request 200 times and here are some
numbers I get:
Bytes written: 200,482,200
Calls to writeToChannel: 1,126,198
Bytes written per call: ~178
This seems pretty fishy to me considering that the buffer is 4096
bytes. My knowledge of NIO is quite limited so I don't have much to
compare these numbers to. Any ideas?
Mike
On 8/18/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> Folks,
>
> Well, looks like things are slightly more complicated than I initially
> asserted. I just could not let this one rest and kept on experimenting.
> As soon as I stopped just stupidly pumping lots of data through the
> socket and started using real HTTP requests things started looking quite
> differently. NIO still sucks when it comes to sending and receiving
> large content bodies (~ 1MB), but it tends to perform much better for
> smaller messages (1KB -100KB). It appears the HTTP data receiver based
> on NIO can indeed parse HTTP headers much faster as I hoped.
>
> Here's the test app I have been using
> http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/tests/performance/PerformanceTest.java
>
> In order to run it one needs the latest SVN snapshot of HttpCommon [1]
> and a reasonably recent version of Tomcat, preferably 5.5 branch. This
> is the server.xml that I have been using [2]. (Please do not forget to
> comment out the other connector on port 8888)
>
> These are my numbers
>
> Windows XP, P4, 1GB
>
> tests.performance.PerformanceTest 8080 200 NIO
> ==============================================
> Request: GET /tomcat-docs/changelog.html HTTP/1.1
> Average (nanosec): 17,832,699
> Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> Average (nanosec): 3,444,763
> Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> Average (nanosec): 49,411,834
>
> tests.performance.PerformanceTest 8080 200 OldIO
> ==============================================
> Request: GET /tomcat-docs/changelog.html HTTP/1.1
> Average (nanosec): 24,436,939
> Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> Average (nanosec): 15,563,380
> Request failed: java.nio.channels.ClosedChannelException
> Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> Average (nanosec): 26,104,509
>
> Oleg
>
> [1]
> http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/http-common/
> [2]
> http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/server.xml
>
> On Wed, 2005-08-17 at 21:48 +0200, 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
Re: [HttpCommon] NIO is one huge disappointment (maybe not)
Posted by Oleg Kalnichevski <ol...@apache.org>.
Folks,
Well, looks like things are slightly more complicated than I initially
asserted. I just could not let this one rest and kept on experimenting.
As soon as I stopped just stupidly pumping lots of data through the
socket and started using real HTTP requests things started looking quite
differently. NIO still sucks when it comes to sending and receiving
large content bodies (~ 1MB), but it tends to perform much better for
smaller messages (1KB -100KB). It appears the HTTP data receiver based
on NIO can indeed parse HTTP headers much faster as I hoped.
Here's the test app I have been using
http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/tests/performance/PerformanceTest.java
In order to run it one needs the latest SVN snapshot of HttpCommon [1]
and a reasonably recent version of Tomcat, preferably 5.5 branch. This
is the server.xml that I have been using [2]. (Please do not forget to
comment out the other connector on port 8888)
These are my numbers
Windows XP, P4, 1GB
tests.performance.PerformanceTest 8080 200 NIO
==============================================
Request: GET /tomcat-docs/changelog.html HTTP/1.1
Average (nanosec): 17,832,699
Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
Average (nanosec): 3,444,763
Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
Average (nanosec): 49,411,834
tests.performance.PerformanceTest 8080 200 OldIO
==============================================
Request: GET /tomcat-docs/changelog.html HTTP/1.1
Average (nanosec): 24,436,939
Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
Average (nanosec): 15,563,380
Request failed: java.nio.channels.ClosedChannelException
Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
Average (nanosec): 26,104,509
Oleg
[1]
http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/http-common/
[2]
http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/coyote-httpconnector/src/tests/server.xml
On Wed, 2005-08-17 at 21:48 +0200, 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
Re: HttpClient Powered - BigBlogZoo
Posted by Dion Gillard <di...@gmail.com>.
It's not clear that
http://wiki.apache.org/jakarta-httpclient/HttpClientPowered only lists
open source projects.
Is that a new requirement?
On 8/19/05, Ortwin Glück <od...@odi.ch> wrote:
>
>
> Kent Gibson wrote:
> > not yet, the thing is that there are only two of us,
> > so I thought it would be better ie more efficient to
> > get it out and established and then consider open
> > sourcing it. I am certainly planning on open sourcing
> > parts of it.
> >
> > Plus there is a central database and and I will need
> > to research other os project that have a database in
> > regards to security issues. All the libraries I use
> > are either apache style license or lgpl or the eclipse
> > license.
>
> Well, please come back when it is OSS.
>
> Cheers
>
> Ortwin Glück
>
> --
> [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
>
>
--
http://www.multitask.com.au/people/dion/
"You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live." - George
Bernard Shaw
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient Powered - BigBlogZoo
Posted by Kent Gibson <ke...@yahoo.com>.
no offense taken here.
I thought I would share something interesting that I
believe I discovered today.
Some servers don't seem to like the standard agent
header, specifically google and a german company
called izzynews. Until I changed the header I was
getting either 403 or 404s. I wonder if this should be
documentated somewhere.
for example:
http://izynews.de/amazon.rel/1027140
http://izynews.de/de/dir/rss/Bildung%20%26%20Wissenschaft.xml
http://izynews.de/monster/1350/3976/10
http://izynews.de/ohg/plce/1404
http://izynews.de/de/dir/rss/Immobilien.Bayern.Neu-Ulm.xml
http://news.google.com/news?ned=us&output=rss&topic=m
--- Ortwin Glück <od...@odi.ch> wrote:
> Oleg Kalnichevski wrote:
> > Wow, Odi. You are just way too harsh with your
> judgements these days.
>
> No offence meant, guys.
>
> > Kent,
> >
> > While we do tend to give a more prominent
> placement to open-source
> > projects, this is not a requirement to be listed
> on the HttpClient
> > powered page. I beleive HttpClient Wiki is world
> writeable. Just create
> > a wiki login, log in, edit the page, and add your
> project to the bottom
> > of the list
> >
> > Cheers,
> >
> > Oleg
>
> Of course Kent may add his application as we have
> not established any
> rules what can be included on that page.
>
> Odi
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpclient-dev-help@jakarta.apache.org
>
>
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient Powered - BigBlogZoo
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> Wow, Odi. You are just way too harsh with your judgements these days.
No offence meant, guys.
> Kent,
>
> While we do tend to give a more prominent placement to open-source
> projects, this is not a requirement to be listed on the HttpClient
> powered page. I beleive HttpClient Wiki is world writeable. Just create
> a wiki login, log in, edit the page, and add your project to the bottom
> of the list
>
> Cheers,
>
> Oleg
Of course Kent may add his application as we have not established any
rules what can be included on that page.
Odi
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient Powered - BigBlogZoo
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, Aug 19, 2005 at 09:12:37AM +0200, Ortwin Gl?ck wrote:
>
>
> Kent Gibson wrote:
> >not yet, the thing is that there are only two of us,
> >so I thought it would be better ie more efficient to
> >get it out and established and then consider open
> >sourcing it. I am certainly planning on open sourcing
> >parts of it.
> >
> >Plus there is a central database and and I will need
> >to research other os project that have a database in
> >regards to security issues. All the libraries I use
> >are either apache style license or lgpl or the eclipse
> >license.
>
> Well, please come back when it is OSS.
>
> Cheers
>
> Ortwin Gl?ck
>
Wow, Odi. You are just way too harsh with your judgements these days.
Kent,
While we do tend to give a more prominent placement to open-source
projects, this is not a requirement to be listed on the HttpClient
powered page. I beleive HttpClient Wiki is world writeable. Just create
a wiki login, log in, edit the page, and add your project to the bottom
of the list
Cheers,
Oleg
> --
> [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
Re: HttpClient Powered - BigBlogZoo
Posted by Ortwin Glück <od...@odi.ch>.
Kent Gibson wrote:
> not yet, the thing is that there are only two of us,
> so I thought it would be better ie more efficient to
> get it out and established and then consider open
> sourcing it. I am certainly planning on open sourcing
> parts of it.
>
> Plus there is a central database and and I will need
> to research other os project that have a database in
> regards to security issues. All the libraries I use
> are either apache style license or lgpl or the eclipse
> license.
Well, please come back when it is OSS.
Cheers
Ortwin Glück
--
[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
Re: HttpClient Powered - BigBlogZoo
Posted by Kent Gibson <ke...@yahoo.com>.
not yet, the thing is that there are only two of us,
so I thought it would be better ie more efficient to
get it out and established and then consider open
sourcing it. I am certainly planning on open sourcing
parts of it.
Plus there is a central database and and I will need
to research other os project that have a database in
regards to security issues. All the libraries I use
are either apache style license or lgpl or the eclipse
license.
--- Ortwin Glück <od...@odi.ch> wrote:
> Is it open source?
>
> Kent Gibson wrote:
> > First of all thanks for the great library, it was
> very
> > useful in creating my application, the BigBlogZoo.
> If
> > one of the developer's wants a free copy of the
> > BigBlogZoo, I will be happy to give a couple of
> copies
> > away. Release date is sometime next week. You can
> try
> > out the beta and tell me if you want a copy. This
> > release also only supports windows.
> >
> > I tried to update the wiki myself but it seems
> > immutable, so if someone wouldn't mind adding this
> to
> > the wiki:
> >
> > BigBlogZoo - www.bigblogzoo.com
> >
> > The BigBlogZoo is a Semantic Web Browser. Nearly
> > 80,000 newsfeeds and blogs have been categorized
> and
> > integrated into a collaborative framework we call
> the
> > Zoo. We present to the user the channel concept,
> much
> > like a television, except for a browser. Users can
> > submit, browse, spider and reaggregate these
> channels.
> > Future enhancements for collaboration will
> include
> > the ability to reorganize and rate channels.
> >
> > take care
> >
> > kent
> >
> >
> >
> >
> ____________________________________________________
> > Start your day with Yahoo! - make it your home
> page
> > http://www.yahoo.com/r/hs
> >
> >
> >
>
---------------------------------------------------------------------
> > 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
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient Powered - BigBlogZoo
Posted by Ortwin Glück <od...@odi.ch>.
Is it open source?
Kent Gibson wrote:
> First of all thanks for the great library, it was very
> useful in creating my application, the BigBlogZoo. If
> one of the developer's wants a free copy of the
> BigBlogZoo, I will be happy to give a couple of copies
> away. Release date is sometime next week. You can try
> out the beta and tell me if you want a copy. This
> release also only supports windows.
>
> I tried to update the wiki myself but it seems
> immutable, so if someone wouldn't mind adding this to
> the wiki:
>
> BigBlogZoo - www.bigblogzoo.com
>
> The BigBlogZoo is a Semantic Web Browser. Nearly
> 80,000 newsfeeds and blogs have been categorized and
> integrated into a collaborative framework we call the
> Zoo. We present to the user the channel concept, much
> like a television, except for a browser. Users can
> submit, browse, spider and reaggregate these channels.
> Future enhancements for collaboration will include
> the ability to reorganize and rate channels.
>
> take care
>
> kent
>
>
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
>
>
> ---------------------------------------------------------------------
> 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
HttpClient Powered - BigBlogZoo
Posted by Kent Gibson <ke...@yahoo.com>.
First of all thanks for the great library, it was very
useful in creating my application, the BigBlogZoo. If
one of the developer's wants a free copy of the
BigBlogZoo, I will be happy to give a couple of copies
away. Release date is sometime next week. You can try
out the beta and tell me if you want a copy. This
release also only supports windows.
I tried to update the wiki myself but it seems
immutable, so if someone wouldn't mind adding this to
the wiki:
BigBlogZoo - www.bigblogzoo.com
The BigBlogZoo is a Semantic Web Browser. Nearly
80,000 newsfeeds and blogs have been categorized and
integrated into a collaborative framework we call the
Zoo. We present to the user the channel concept, much
like a television, except for a browser. Users can
submit, browse, spider and reaggregate these channels.
Future enhancements for collaboration will include
the ability to reorganize and rate channels.
take care
kent
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpCommon] NIO is one huge disappointment
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, Aug 18, 2005 at 12:00:24PM +0200, Ortwin Gl?ck wrote:
>
>
> Oleg Kalnichevski wrote:
> >Odi,
> >
> >As soon as I see NIO w/ select outperform old IO by 10-15% at least
> >ONCE I may believe this is just a statistical jitter. Until then old IO
> >consistently outperforming NIO w/select by 10-15% looks horribly like
> >a performance penalty to me ;)
>
> Yes, this is what a reasonable brain does. I tend to think the same way,
> even though it is not accurate in scientific terms.
>
> >You are welcome to give System.nanoTime() method a shot which supposedly
> >is more precise than System.currentTimeMillis()
>
> Good idea. I have never used it before.
>
> >I have put WAY more effort into writing the damn NIOHttpDataReceiver
> >than the entire HTTP coyote connector, and it REALLY pains me to have
> >found this code useless (at least in HttpCommon). At the same time I
> >rather keep HttpCommon lean and mean, and use NIO where it make sense,
> >that is in HttpAsynch.
> >
> >Oleg
>
> That is a bit of a disappointment of course. But this is only a
> laboratory test. With a real load (multiprocessor, many connections,
> heavy load) the figures could be the other way round. But see the good
> side: you can now exchange the implementation easily now. Your efforts
> have certainly not been spent for nothing!
>
> Odi
>
Odi,
Mistakes and design flaws can be expected in the course of development.
We just have to be able to admit them and after having done so fix the
problems. Presently NIO just does not seem to provide any tengible
benefits for blocking i/o at the price for much, much greater
complexity. I hoped the NIO should enable us to be more efficient when
parsing HTTP headers, if byte to char conversion could be sped up with
ByteBuffer, CharBuffer, and Char*coders. However, if one saves a few
milliseconds parsing HTTP headers and loses several times more when
retreiving the content, it just does not make a lot of sense to me.
I do not mind leaving NIO based HTTP data receiver and transmitter
alone, if you think it is still premature to give up on NIO yet.
However, we'll have to revist this problem before the new API is frozen.
Cheers,
Oleg
> --
> [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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> Odi,
>
> As soon as I see NIO w/ select outperform old IO by 10-15% at least
> ONCE I may believe this is just a statistical jitter. Until then old IO
> consistently outperforming NIO w/select by 10-15% looks horribly like
> a performance penalty to me ;)
Yes, this is what a reasonable brain does. I tend to think the same way,
even though it is not accurate in scientific terms.
> You are welcome to give System.nanoTime() method a shot which supposedly
> is more precise than System.currentTimeMillis()
Good idea. I have never used it before.
> I have put WAY more effort into writing the damn NIOHttpDataReceiver
> than the entire HTTP coyote connector, and it REALLY pains me to have
> found this code useless (at least in HttpCommon). At the same time I
> rather keep HttpCommon lean and mean, and use NIO where it make sense,
> that is in HttpAsynch.
>
> Oleg
That is a bit of a disappointment of course. But this is only a
laboratory test. With a real load (multiprocessor, many connections,
heavy load) the figures could be the other way round. But see the good
side: you can now exchange the implementation easily now. Your efforts
have certainly not been spent for nothing!
Odi
--
[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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, Aug 18, 2005 at 11:26:21AM +0200, Ortwin Gl?ck wrote:
>
>
> Oleg Kalnichevski wrote:
> >On Thu, Aug 18, 2005 at 10:39:02AM +0200, Ortwin Gl?ck wrote:
> >
> >>
> >>Oleg Kalnichevski wrote:
> >>
> >>
> >>>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
> >>
> >>Okay.
> >>
> >>
> >>>(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
> >>
> >>Ok, with 10 times as much data (10 MB), I get:
> >>
> >>Old IO average time (ms): 121
> >>Blocking NIO average time (ms): 119
> >>NIO with Select average time (ms): 133
> >>
> >>The jitter is now around 10-15%. So the three values still are all in
> >>the same statistical bucket. That means there is no notable performance
> >>difference below 10 MB of data.
> >>
> >
> >Odi,
> >I think 10-15% performance penalty is considerable.
>
> 10-15% is the *jitter*, not the performance penalty.
Odi,
As soon as I see NIO w/ select outperform old IO by 10-15% at least
ONCE I may believe this is just a statistical jitter. Until then old IO
consistently outperforming NIO w/select by 10-15% looks horribly like
a performance penalty to me ;)
You are welcome to give System.nanoTime() method a shot which supposedly
is more precise than System.currentTimeMillis()
I have put WAY more effort into writing the damn NIOHttpDataReceiver
than the entire HTTP coyote connector, and it REALLY pains me to have
found this code useless (at least in HttpCommon). At the same time I
rather keep HttpCommon lean and mean, and use NIO where it make sense,
that is in HttpAsynch.
Oleg
If I measure 133 ms
> for NIO then these 133 ms are an avarage of 20 individual values with 15
> ms of uncertainity each. That means the value 133 ms has an uncertainity
> of 15 ms as well (which is 11%) : The "real" value is between 118 and
> 148 ms. So the above numbers have the following meaning:
>
> Old IO average time (ms): 106 - 136
> Blocking NIO average time (ms): 104 - 134
> NIO with Select average time (ms): 118 - 148
>
> or graphically:
>
> ******************************* [IO]
>
> ******************************* [bIO]
>
> [nbIO] *******************************
>
> |---------|---------|---------|---------|---------|
> 100 110 120 130 140 150
>
> Thus it may be possible that, despite the actual figures, nbIO is
> actually faster than IO.
>
> Sorry for being pedantic. It's just that I am a physicist and I was
> taught how to properly perform a measurement.
>
> > Besides, on some
> >platforms, admittedly misconfigured or having poor JRE implementation,
> >the cost of having a channel selector per channel is simply prohibitive.
> >
> >I am still of an opinion we gain absolutely nothing by using NIO for
> >API that is not specifically designed to make heavy use of non-blocking
> >IO with hundreds of channels managed by one channel selector.
> >
> >Oleg
>
>
> --
> [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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> On Thu, Aug 18, 2005 at 10:39:02AM +0200, Ortwin Gl?ck wrote:
>
>>
>>Oleg Kalnichevski wrote:
>>
>>
>>>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
>>
>>Okay.
>>
>>
>>>(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
>>
>>Ok, with 10 times as much data (10 MB), I get:
>>
>>Old IO average time (ms): 121
>>Blocking NIO average time (ms): 119
>>NIO with Select average time (ms): 133
>>
>>The jitter is now around 10-15%. So the three values still are all in
>>the same statistical bucket. That means there is no notable performance
>>difference below 10 MB of data.
>>
>
> Odi,
> I think 10-15% performance penalty is considerable.
10-15% is the *jitter*, not the performance penalty. If I measure 133 ms
for NIO then these 133 ms are an avarage of 20 individual values with 15
ms of uncertainity each. That means the value 133 ms has an uncertainity
of 15 ms as well (which is 11%) : The "real" value is between 118 and
148 ms. So the above numbers have the following meaning:
Old IO average time (ms): 106 - 136
Blocking NIO average time (ms): 104 - 134
NIO with Select average time (ms): 118 - 148
or graphically:
******************************* [IO]
******************************* [bIO]
[nbIO] *******************************
|---------|---------|---------|---------|---------|
100 110 120 130 140 150
Thus it may be possible that, despite the actual figures, nbIO is
actually faster than IO.
Sorry for being pedantic. It's just that I am a physicist and I was
taught how to properly perform a measurement.
> Besides, on some
> platforms, admittedly misconfigured or having poor JRE implementation,
> the cost of having a channel selector per channel is simply prohibitive.
>
> I am still of an opinion we gain absolutely nothing by using NIO for
> API that is not specifically designed to make heavy use of non-blocking
> IO with hundreds of channels managed by one channel selector.
>
> Oleg
--
[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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, Aug 18, 2005 at 10:39:02AM +0200, Ortwin Gl?ck wrote:
>
>
> Oleg Kalnichevski wrote:
>
> >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
>
> Okay.
>
> >(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
>
> Ok, with 10 times as much data (10 MB), I get:
>
> Old IO average time (ms): 121
> Blocking NIO average time (ms): 119
> NIO with Select average time (ms): 133
>
> The jitter is now around 10-15%. So the three values still are all in
> the same statistical bucket. That means there is no notable performance
> difference below 10 MB of data.
>
Odi,
I think 10-15% performance penalty is considerable. Besides, on some
platforms, admittedly misconfigured or having poor JRE implementation,
the cost of having a channel selector per channel is simply prohibitive.
I am still of an opinion we gain absolutely nothing by using NIO for
API that is not specifically designed to make heavy use of non-blocking
IO with hundreds of channels managed by one channel selector.
Oleg
> Odi
>
> --
> [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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> 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
Okay.
> (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
Ok, with 10 times as much data (10 MB), I get:
Old IO average time (ms): 121
Blocking NIO average time (ms): 119
NIO with Select average time (ms): 133
The jitter is now around 10-15%. So the three values still are all in
the same statistical bucket. That means there is no notable performance
difference below 10 MB of data.
Odi
--
[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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Ortwin Glück <od...@odi.ch>.
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 <ol...@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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Michael Becke <mb...@gmail.com>.
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 <ol...@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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
Re: [HttpCommon] NIO is one huge disappointment
Posted by Eric Johnson <er...@tibco.com>.
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