tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Petr Sumbera <Petr.Sumb...@Sun.COM>
Subject Re: Tomcat with/without Tomcat native library
Date Thu, 02 Aug 2007 09:14:09 GMT
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" <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