The "Sends (ms)" column reflects the timeout between client sends. I originally intended to run these tests for many timeouts, but this became prohibitively annoying over the WAN. These tests were done with all clients running on a single machine connecting to the servers over the WAN.
Thanks.
-Adam
Jeanfrancois Arcand wrote:
Adam Fisk wrote:
Just to chime in on the NIO issue, I agree that it's not immediately obvious what the performance benefits are. Perhaps more importantly, though, the code changes to switch Tomcat (or any other good-size app) to NIO are tremendous -- basically a rewrite of the hard parts.
That said, I've done simple tests of NIO vs. blocking IO on Windows using simple blocking and non-blocking servers with variable numbers of client connections (from 100 to 10,000). At least on Windows, the performance benefits come down to memory allocated to threads. My blocking server used one send thread and one receive thread per connection (no thread pooling). Given the memory allocations per thread, though, the blocking server with 1600 connections used 137MB whereas the NIO server used 11MB, almost exactly the same as the memory use with 50 connections.
I'd be happy to send my data to the group if people are interested.
Yes, I will be very interested to see those numbers.
Thanks,
-- Jeanfrancois
Aside from memory, I was surprised to find that the effect on CPU was negligible (not much of a benefit from no context-switching between threads) -- CPU was virtually the same in both cases. So, the scaling benefits on Windows basically come from not having to allocate more memory to new threads. I'm unfortunately not as familiar with the Tomcat code as I'd like to be, but I assume it makes intelligent use of thread pooling, which may even the memory benefits of NIO negligible. At the same time, though, NIO may remove some of the constraints introduced by thread pooling, possibly allowing Tomcat to handle heavier loads without blowing up. An optimized NIO server would if anything out-perform a blocking server, but maybe by not that much.
-Adam
Remy Maucherat wrote:
Jan-Henrik Haukeland wrote:
Remy Maucherat <[EMAIL PROTECTED]> writes:
My opinion is that NIO is going to be really useless.
Eh, hello!? Oh, okay if it's not important that Tomcat scale and perform well it may be useless. But, really, before NIO it was hopeless to try and write a scalable and fast tcp server application in Java. Tomcat's current connection handling with blocing all over the place and "thundering herd" problem doesn't scale or work very well under heavy load.
You apparently have a very strong opinion on this, and that's fine. You also obviously don't know what you are talking about. The purpose of Tomcat is to make the web tier of an application server (Tomcat is actually a mini application server), not some kind of non blocking I/O toolkit to be used to build fixed function servers. Non blocking I/O has great applications, and is a very useful technology, but it does not apply to the application server world.
I think you should find a servlet container which has NIO, compare with Tomcat 5.0.16, and come back to report your findings about how much scalability or speed NIO brings (note: doing the non blocking socket handling in a native layer doesn't really count, since it's not a fair comparison with Java's NIO; you might as well use Apache).
Bring facts, not useless rants.
Rémy
--------------------------------------------------------------------- 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]
.
blocking_vs_non-blocking.xls
Description: MS-Excel spreadsheet
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
