hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject HttpClient benchmark; was RE: [Httpcomponents Wiki] Update of "HttpClient3vsHttpClient4vsHttpCore" by OlegKalnichevski
Date Fri, 11 Mar 2011 08:15:31 GMT
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message