On Fri, 2011-07-15 at 14:14 -0400, Bill Speirs wrote: > On Fri, Jul 15, 2011 at 12:41 PM, Oleg Kalnichevski <[email protected]> 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. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
