tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Tomcat with/without Tomcat native library
Date Thu, 02 Aug 2007 02:55:43 GMT

"Mladen Turk" <> wrote in message
> Petr Sumbera wrote:
>> Hi Bill and all,
>> not sure what is the right way for comparison between using and not using 
>> APR. I tried Apache ab tool like this:
>> ab -c 4 -n 10000 http://localhost:8080/favicon.ico
>> And I don't see any difference. Actually it might be little bit slower 
>> with APR. The file size is 21630, so it should use sendfile then (well 
>> actually our APR doesn't use sendfile at the moment as far as I know).
> The purpose of APR is to change the model from thread-per-connection
> to thread-per-request. This means it will behave much faster when
> you have 1000 concurrent clients using Keep-Alive (HTTP 1.1).

I agree with Mladen here.  Your test is artificial, so under most systems 
the non-APR connector will win (since you only have 4 clients connecting to 
TC).  And since you haven't specified '-k' to ab, you are really testing 
connection speed, which isn't realistic.

On Solaris, having a 1000 threads blocking on input isn't that big of a 
deal, so I'm not sure about the "much faster" claim, but I haven't profiled 
Tomcat lately :).

> In that case you'll be able to serve them all with lower number
> of maxThreads.
> So, try to use the 'normal' test tool instead a brute force one like 'ab'
> that will reflect the real load to your boxes.
> I mean, the ab (Apache Bench) is a DoS tool, right ;)

When I was profiling, I used JMeter and 500 clients with about a one minute 
ramp-up time (I don't care about how it handles an accept flood), and about 
a 5-10 second delay between requests (I don't have the script I used 
anymore, so I don't remember the exact value).  Also, if you use JMeter, use 
the HttpClient Sampler or configure the Sampler to use a bigger 
than default pool, since by default the Sampler doesn't scale up to 
this level (skewing the results).  Also interesting would be to use a longer 
connectionTimeout on the <Connector /> and longer delays between requests. 
But for a good comparision, make sure that the maxThreads attribute on the 
<Connector /> is large enough to handle the lode.

> Regards,
> Mladen.
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message