Mladen Turk wrote:
Vicenc Beltran Querol wrote:
Hi guys,
I'm not trying to be a Tomcat developer. I'm working on my PhD on web performance and just decided to share with you the experimental code I've developed after studying the performance obtained ;).
I've done some serious testings with HTTP server and NIO. The results were always bad for NIO. Blocking I/O is minimum 25% faster then NIO.
Faster in what? Throughput and/or scalability?
I disagree ;-) I would like to see your implementation, because from what I'm seeing/measuring, it is completely the inverse. I would be interested to see how you did implement your NIO connector. The problem with HTTP is not NIO, but the strategy to use for predicting if you have read all the bytes or not. Falling to implement a good strategy will ends up parsing the bytes many times, calling the Selector.wakeup() too often, thus poor performance. The way you register your SelectionKey is also very important.
Also, blocking IO required 1 thread per connection, which doesn't scale very well. That's why I think the new APR connector is interesting, since it fix that problem. But even if with APR, you did workaround the JNI bottleneck by using direct byte buffer, I suspect a pure NIO implementation will perform better than APR (except for static resource) just because of the C->Java overhead. But I don't have yet numbers to show...come to my session at JavaOne, I will :-)
You may tray that simply by using demo HTTP servers Blocking/Blocking Pool/NIO single thread/NIO multiple threads that comes with new Java6 (see java.net for sources).
Right. This is actually a good example not to follow ;-).
BTW the big patch use NIO blocking, which may improve scalability, but will impact throughput. The patch should be improved to use NIO non-blocking. And then we can compare ;-)
-- Jeanfrancois
OTOH, I'm sure you must have some performance results :) Simply run the 'ab -n 100000 -c 100 -k host:8080/tomcat.gif' with your patch and standard Tomcat5.5.9.
Anyway, it's OK. I'll work on the new patch and resubmit it.
Great.
Regards, Mladen.
--------------------------------------------------------------------- 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]
