hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jared Jacobs <ja...@kaching.com>
Subject Re: Poor performance of pooled connections worse in 4.0
Date Thu, 12 Nov 2009 19:27:00 GMT
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.


On Thu, Nov 12, 2009 at 5:38 AM, Tony Poppleton

> 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: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message