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? 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: [email protected] For additional commands, e-mail: [email protected]
