----- Original Message ----- From: "Jeanfrancois Arcand" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sent: Friday, May 20, 2005 6:56 AM
Subject: Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
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.
Yeah, the speed improvement with NIO is the only thing that makes ChannelNioSocket not a total PoC. It's really depressing that any JVM vendor would allow such a huge performance difference between Socket.getOutputStream().write and SocketChannel.write.
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]
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
