hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpCommon] NIO is one huge disappointment (maybe not)
Date Fri, 19 Aug 2005 16:17:10 GMT
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 <olegk@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


Mime
View raw message