You might consider checking out the latest Dr. Dobb's. They have an article about NIO. The article is available on the www.ddj.com web site, but unfortunately it looks like you have to pay to get it.
-----Original Message----- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 11:41 AM To: HttpClient Project Subject: Re: [HttpCommon] NIO is one huge disappointment (maybe not) 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-httpconn ector/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-httpconn ector/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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
