On 11 March 2011 08:15, Oleg Kalnichevski <[email protected]> wrote: > 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.
@Oleg: Ping? >> >> 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. Perhaps the echo code can be replaced with something that does a similar amount of work on the server? >> 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) Also, repeating the tests multiple times should show if there is much variation. > Hope this helps > > Oleg > > > > --------------------------------------------------------------------- > 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]
