On Fri, 2011-03-11 at 07:19 +0100, Hubert, Eric wrote: > Hi > > > The first section under 500'000 requests / up to 250 concurrent > > connections does not specify the client used: > > I assume this is probably HTTP agent: Apache HttpClient 3.1 but it > > would be good to add it to the page. > > I noticed the same, sharing this assumption. ;-) > > Additionally I would be interested in some background information > helping to interpret the results. > For easier readability I put all results concentrating on just a > Single metric in one table (truncated req/second - hope I did > not messed some numbers). > > Conc 20 (get/post) Con 250 (get/post) > Client 3.1 16170 / 16788 8188 / 9792 > JRE 6u18 21705 / 16882 14446 / 14358 > Core 4.1 31438 / 24236 19705 / 17815 > Client 4.1 25154 / 22520 21360 / 21762 > Client 4.2 24069 / 19929 21675 / 18270 > Jetty 7.2.0 7734 / 8140 19948 / 20016 > Jetty 7.3.1 17727 / 17828 20903 / 18250 > > The following questions came into my mind > (please excuse if answers are obvious!) > a) Why performs 3.1 better for POSTs than for GET?
I do not have a good answer to this question, just a guess. I suspect that it simply takes longer to generate random content on the server side when responding to GET requests and to do a simple echo when responding to POST requests. > b) Why is 4.2 Http Client faster than plain Http Core 4.1 for concurrency This one I know for sure. This is the effect of connection pooling. HttpCore does not support connection pooling and therefore has to maintain 250 physical connections. Apparently, for a large number of threads fewer shared connections tend to perform better than a large number of non-shared connections. > level of up to 250 (for up to 20 conc. Connections it is the opposite, which > seems to be obvious). > c) What is the reason for the performance degradation for POST between > Http Client 4.1 and 4.2? Benchmark numbers do tend to fluctuate somewhat. I see no reason why HC 4.2 should be slower than 4.1. They share exactly the same core as the moment. > (The test runs have to be performed on the same hardware, or? Yes. They would be meaningless otherwise. > Only expected volatility between test runs (more than 10%)? I can't really say. The only way to get better data / less volatility in the benchmark in my opinion is to execute test runs longer (have more requests to execute) Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
