I'm not a committer, but I think evidence proves that native sockets + JNI is the way to go. To my knowledge, weblogic, websphere and Resin all use native sockets. having a pure Java approach sounds nice and all, but in the edge cases where high concurrent connection is needed, I much rather go with native + jni.
my 1/10th of a cent worth. peter On 5/20/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: > Jeanfrancois Arcand wrote: > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
