hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Speirs <bill.spe...@gmail.com>
Subject Re: HttpClient Performance Issues
Date Fri, 15 Jul 2011 18:14:15 GMT
On Fri, Jul 15, 2011 at 12:41 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
> This can be expected. 100 concurrent threads simultaneously try to open
> 100 connections which is a costly operation. Once connections are up and
> running the request per second ratio becomes normal.

What inside of the request is taking up to 6 seconds to setup the
connection? Is there any way to bootstrap this? I know that I'll be
making numerous connections to the same server. I am using the version
of execute which takes an HttpHost as an argument, and I thought the
creation of the HttpHost object would alleviate any issues with
bootstrapping.

> In my tests HttpClient 4.1 greatly outperforms Ning async HTTP client
> which is based on Netty.

I confuse Netty & Jetty all the time... my apologies.

I was using the code in TestJettyHttpClient.java as the basis for my
test. That code however appears to NOT be concurrent, but the time to
make requests is constant across all 1,000 requests. How can I get
HttpClient 4.1 to perform like that Jetty implementation?

> Just make sure that 100 threads to do not attempt to obtain a connection
> from the connection pool all at the same time or make sure the benchmark
> runs long enough to make 100 first requests not so important.

What exactly is causing this contention? Is it a locking data
structure for the connection pool, or something else network related
like DNS resolution?

Thanks...

Bill-

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message