Jared Jacobs wrote:
What is the point of having 10 connection limit and using 50 worker
threads?
To simulate heavy load (more demand than supply). It's irrelevant. Make the
numbers the same and you'll still see the latency problem.
With 50 requests you will not even warm up the JIT compiler. You have to
be doing 200,000 requests at the very least.
Regardless of what the max connections per host limit is set to, though, at
least the first request should not block at all.
Why?
Because the pool is empty the first time around. To be clear, I meant block
*waiting for a connection from the pool to become available*.
It takes some time to set up a pool and open a connection.
All these numbers are meaningless given such a small number of requests.
You should be executing 10,000 HTTP requests in order to get any meaningful
performance data.
In our production environment, we're talking to reliable services with
strict SLAs over fast, reliable connections. We do tens of thousands of
requests, and as I mentioned in my first email, we saw a large increase in
request times when we upgraded from httpclient 3.1 to 4.0.
Some things become clearer when you isolate factors. Hence my benchmarks.
Any statistician will tell you that when the minimum of 50 samples increases
by 10x, it is statistically significant. The samples are coming from two
very different populations.
Oleg, I've sent you my benchmark source code off-list. Feel free to use it,
or not. I would be interested in any performance measurements that you or
someone else at Apache has done.
Your benchmark is meaningless. You are comparing the execution speed of
50 request over 50 connections to 50 requests over 10 connection. WHAT
IS IT _EXACTLY_ you are trying to measure with your benchmark?
Here's the code I used to compare _throughput_ in terms of requests per
second of different HTTP client transports.
Feel free to adapt this code to your particular needs
http://wiki.apache.org/HttpComponents/HttpClient3vsHttpClient4vsHttpCore
Oleg
Best regards,
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
