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 :-)
Sorry, but I agree with Mladen. There is simply no way a pure non blocking NIO strategy is going to work. It is an attempt to apply receipes which work really well for certain types of takss to other types of tasks. Translated, it would work spectacularly well for, say, a servlet like the default servlet and a small file (ie, small bufferable amount of data + no processing), but fail for a servlet which receives a lot of uploading or more generally has a long processing time. The main problem is that to keep contention on IO low, a low amount of processors has to be used, which is not compatible with the second type of tasks. The only way to apply NIO to Tomcat is to use it in blocking mode, as in the submitted patch.
The only way to convince me your solution can work is to (also) write your own endpoint / protocol handler (this seems trendy these days for some reason, so I guess it's ok if everyone does it ;) ) so I can test it myself and see the results.
As APR matches the numbers of classic blocking IO in the (100% throughput oriented, and worst case; at least, it's the case which favors regular blocking IO the most) ab -k -c 20 localhost/tomcat.gif, it seems hard to beat.
<rant>
BTW, about the NIO usage for optimizing JNI, I'm actually really mad about Sun. Why attempt to make any JNI calls "safe" and make performance suck in the first place, when with native code usage it is trivial to segfault the whole process anyway (example: feed APR a bad address) ? This really makes no sense to me, and seems simply a plot to try to force people to write 100% Java code.
All that complexity and crappy performance for *nothing* (except helping .not and mono, of course) ...
</rant>
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 ;-)
You're going to have to prove your point in a big way ;) There were articles on the subject advocating the same thing, but if you looked a little into it, you could just see how to make the whole thing break really easily.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
