Hi, >The APR connector has a trick to optimize pipelining (where a client >would do many requests on a single connection, but with a small delay >between requests - typically, it would happen when getting lots of >images from a website).
What's the trick? Are you trying to do blocking read operations with really short timeouts trying to create false pipelines, as I've already seen in other scenarios? Because it is only helpful when working in a really sinthetic environment (AB in a very-low-latency LAN). Have you ever tried the APR connector in a WAN? The Hybrid connector is already optimized for real pipelined HTTP requests. Anyway, as far as I know, the AB does not use HTTP pipelining. In my opinion, you're trusting in an unreal behavior of the clients, assuming very low time periods between one response is send and a new request is received for a given client. >Maybe this could be added here as well. Removing this optimization will >make piepelining performance go down as well. Note that Mladen tells >me of more sendfile-like performance tricks that can't be matched by >NIO (at least for now). I'm absolutely disconcerted. In your previous answeryou agreed that the AB test is not good for comparing two different architectural approaches. And you still wanna compare the performance of the hybrid architecture using it. But when I look for APR results on the net, I find that in the message 70876 (http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg70876.html) of this list that you're using JMeter and think-times in other experiments. Have you looked at any of the results I've post for realistic benchmarks? Why are you so obsessed with the AB results with concurrency level 20? Sorry, but I don't see the point on it... Using non-realistic benchmarks and very-oriented performance tricks only leads to winning few milliseconds in the response time of the server. But it's not a real benefit for the clients. When the server is overloaded (when performance improvements are really determinant), these benefits are negligible... In my opinion, following these development criterias is counterproductive and makes the server worse in the real world (where users put it into production). Surely, you disagree... >Another test which could be done is comparing performance without the >"-k" setting of ab (removing the impact of any pipelining opimization, >but more of the overhead is then on the TCP stack rather than on the >connector). If we move to an HTTP/1.0 scenario, why do we need to change the connector architecture? The multithreaded connector would be a good choice then... >I still don't like the proposed NIO solution, however, as it adds a lot >of complexity to the default thread pool (which was complex already, >but with those changes, it becomes black magic, and robustness will >likely go down). The thread pool is unmodified in the hybrid connector. The only modifications are done in the leaderfollower code, to use NIO operations. In my tests, the robustness has been supreme. At least, as good as the out-of-the-box Tomcat. >If doing NIO, I think a much simpler thread pool structure should be >used instead, like the APR endpoint does (even better, it could be a >Java 5 version taking advantage of the new thread pool APIs). Is JNI simpler? >I expect Jean-Francois to live up to the hype and produce less >experimental code ;) Sure... :) I've one final question about the APR architecture. Have you implemented any kind of admission control mechanism on it? It's great to read your opinions... ;) Best, Vicenç --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
