Hi Tony. Oleg was right to question my initial benchmark. In the connection pool benchmark, I was only issuing one request per thread, and contrary to my intuition, each thread runs slowly at first, even if other threads have already run the same code (i.e. it has already been JIT compiled). Subsequent requests in each thread were much faster. It didn't take anywhere near 10,000 requests to reach stable, optimal performance, though. The second and third requests in each thread, for example, were just as fast as the rest.
You might be wondering if the slowness of the first request that I'm talking about can be attributed to establishing an HTTP connection that is then reused by subsequent requests. Nope. I saw the same effect even when using a new HttpClient per request (i.e. no connection pooling or reuse). Initially, my observations on one of our production servers rose two questions in my mind: 1) Is the overhead for pooling and reusing connections greater than the overhead of establishing new HTTP connections? 2) Is the performance of pooled connections significantly worse in HttpClient 4.0 than in 3.1? After improving my benchmarks, I've concluded that, in general, the answer to both questions is "no" (as one would expect). Reusing connections increases throughput a bit when there's a steady stream of requests that need to be made to a particular host, and 4.0's ThreadSafeClientConnManager performs roughly as well as 3.1's MultiThreadedHttpConnectionManager. Our server that was having problems was both low on memory and occasionally CPU bound. I believe it was those conditions that made 4.0's ThreadSafeClientConnManager slow for us when we first switched to it in production. I'm still not certain which configuration minimizes request latency when requests need to made to a single host pretty often, but at random times. I hope to have the time to answer this question for our use case by experimentation in the coming week. Regards, Jared On Thu, Nov 12, 2009 at 5:38 AM, Tony Poppleton <[email protected]>wrote: > Hi Jared, > > I would be very interested to know if you have made any further progress on > this potential problem. > > Thanks, > Tony > > Jared Jacobs wrote: > >> Thanks again for your response, Oleg. >> >> We're dealing with a latency problem. The total duration of each and every >> request needs to be reliably small. Throughput isn't very important in our >> application. >> >> I'll get to the bottom of the issue with some profiling. >> >> Cheers, >> Jared >> >> >> --------------------------------------------------------------------------------------- >> Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. >> Aucun virus connu a ce jour par nos services n'a ete detecte. >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
