Thank you both for the info. But what is your opinion about the crash I
am experiencing with SSL:
bash-3.00# /usr/apache2/bin/ab -c 4 -n 10000
https://localhost:443/favicon.ico
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
SSL handshake failed (5).
Test aborted after 10 failures
apr_socket_connect(): Connection refused (146)
Total of 1 requests completed
--
I understand that test is not good but Tomcat shouldn't crash, right?
Thanks,
Petr
"Mladen Turk" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
