hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HttpClient Performance Issues
Date Fri, 15 Jul 2011 18:56:05 GMT
On Fri, 2011-07-15 at 14:14 -0400, Bill Speirs wrote:
> 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?

What makes you think the time was wasted inside HttpClient code? Your
computer might have had a sudden urge to swap some data to disk or there
was a temporary glitch in the Matrix or what not. The point is as long
as there is one such request for a thousand 'normal' ones one outlier is
simply irrelevant.

>  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?

If you are fine with executing requests sequentially simply use one
thread to execute requests and utilize simple (single-connection)
connection manager instead of the pooling one.

> > 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?

Could be anything or all these factors combined.


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

View raw message