tomcat-users mailing list archives

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

"Mladen Turk" <mladen.turk@gmail.com> wrote in message 
news:46B09369.9060504@gmail.com...
> 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 java.net Sampler to use a bigger 
than default pool, since by default the java.net 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: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> 




---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message