Well, the strategy you use is important. If you can predict the size of the stream (by let say discovering the content-length), you can make uploading task as fast as with blocking IO (OK, maybe a little slower since you parse the header, and the channel may not reads it fully in its first Selector.select()). But for GET operation, it shouldn't be a problem.
That's not good, we have to provide a general solution. Of course, in some cases, it can work out great. I assume also the way to get around it if you get the content-length is to buffer (actually, the only actual solution is to buffer all uploads), so this simply moves scalability to somewhere else.
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.
Right, I agree this is the way to go ;-). Replacing the current thread pool doesn't hurt also (but maybe it's only me..this pool is way to complex for what it does).
I did revert back to using the old Tomcat 4.0 thread pool for the APR endpoint, because that pool style is more predictable (when something fails during accept) and configurable (the priority of the accept thread can be configured independently).
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.
Well, I agree but I'm not really interested about static resource. I'm
Right, nobody is ever interested, but in the end this shuts out Java from most of the web server market.
The default servlet is merely an example of a servlet which does almost no processing, and returns a little data. It's not meant to be a true static file test (for that kind of test, there will be no filesystem access). You can also write a servlet which would output a 1KB byte array, it's the same.
more interested to benchmark a real JSP/Servlet application, that contains both static and dynamic resources. I think APR will always be faster that NIO non blocking for static resources. But non blocking will be faster than the current Coyote/http11 connector, by applying the same trick you did for DefaultServlet sendFile implementation, and by using MappedByteBuffer to load the resource in FileDirContext.
No, don't even to optimize this for now, it's not the thing I'm interested in (sendfile will only be used in the default APR config if the file is larger than 48KB).
But all I'm saying needs numbers, which I will have in June :-)
<rant>
BTW, about the NIO usage for optimizing JNI, I'm actually really mad about Sun.
Haha. Have you ever be happy with SUN :-) Probably only the day you hired me (LOL) and asked me to implement XML schema supports (beurk!) :-)
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) ?
I agree. But seems the "safe" lobbyist were stronger that others...
I guess :) Obviously, I didn't do any JNI until now, so I didn't actually care earlier.
I agree...but the strategy used just sucks. Having a pipe between the Read Thread and the Processor Thread might looks good on paper, but that's clearly not a good strategy. Also the NIO implementation in Jetty is clearly bad. EmberIO framework looked promising, but seems little activity happenned after the big annoncement....
I see only two strategies personally ;) I suppose it shows the API is probably too complex. Personally, the main strategy I used with APR is to minimize the amount of calls, and then optimize the passing around of byte arrays, but neither of these choices is caused by APR itself.
Still, if APR is faster, then I will say it is. But to convince me, I need to compare real implementation.
In addition to the obviously inetresting features (epoll/sendfile/openssl), there are all sorts of other useful uses for APR, as I mentioned earlier. Getting it inside Tomcat makes it a Java version of httpd in terms of core capabilities, and will likely open all sorts of features and possibilities in a very simple way.
So if someone can do something which scales well for pure Java users, then it's great to have it, but it's only a part of the equation (and it's likely not going to remove the need for APR).
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
