On 5/23/2013 4:53 AM, Chirag Dewan wrote:
Hi All,
I tested Tomcat 7.0.40 with Solaris x86. It gave better CPU performance than
Tomcat 7.0.30 . It was able to handle 70K requests at 45% CPU utilization which
is still behind my bench mark of 70k requests at 25-30% utilization with
Tomcat 6.
I also tested with Tomcat 6.0.37 and the results were more or less same as
Tomcat 6.0.18
One thing I observed,I ran 3 clients pointing to 3 different static HTML pages.
With Tomcat 6(both 6.0.18 and 6.0.37) each client gave me a concurrency of 48k
req/sec at 50-55% CPU utilization. However when I ran the same test case for
Tomcat 7(7.0.40 and 7.0.30) the req/sec were divided b/w the clients and the
total concurrency was consistent around 70k with 45% utilization. Now no matter
how many clients I run,the req/sec is constant. This is a bit strange. What
could possibly be the reason?
Maybe you're saturating the bandwidth or maxing out some other resource
not connected to the tomcats?
I am not sure I would be able to upgrade to Tomcat 7 under these circumstances.
Thanks.
________________________________
From: Christopher Schultz<ch...@christopherschultz.net>
To: Tomcat Users List<users@tomcat.apache.org>
Sent: Wednesday, 22 May 2013 7:30 PM
Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat
7
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Chirag,
On 5/21/13 11:03 PM, Chirag Dewan wrote:
I was monitoring the CPU utilization specifically. I can
compromise on 10000 less transactions/sec,but 80-90% utilization is
not good.
While it's nice to reduce resource utilization as much as possible,
why would you want your server to run at 25% CPU all the time? That's
a waste of 75% of the CPU available.
The test you are performing sounds like a peak-load test (100
simultaneous connections is pretty decent load). At peak load, you
have 10-20% breathing room before your CPU can't keep up. Sounds like
you have an appropriately-sized server for the type of load you expect.
Do you have some kind of performance benchmarks that you have to hit?
I have configured 1000 max threads in the connector,and I am
testing with 100 concurrent threads.
So you have 10 times the number of threads available than necessary.
Did you do that simply to make sure that the thread-pool wouldn't be
the problem?
What kind of connector are you using? Re-reading the thread it looks
like you are using the BIO (default) connector. I'm not sure switching
to NIO or APR would help raw throughput unless you are using SSL
(switch to APR) or have lots of dropped keepalive connections (switch
to NIO - or APR?).
Well I tested a sample html page with Tomcat 6.0.18 and 7.0.30 on
Solaris x86 server. The req/sec were almost the same for both,but
CPU utilization for Tomcat 6 was 23-27% and for Tomcat 7 it was
80-90% consistently.
What about Tomcat 6.0.37?
On the other hand on a Linux system,the req/sec were a little
higher in Tomcat 7 say 65k to 55k on tomcat 6 and the CPU
utilization was the same for both 6 and 7.
... and what was that CPU utilization?
My Jprofiler stack trace on Solaris is a lot different. As far as
I have observed,for Tomcat 7 the stack Trace leads me to
ResponseFacade.setContentType,which was not the behaviour in
Tomcat 6. Can that be a bottleneck?
See Mark's message: there have been some changes to how Tomcat
performs a setContentType -- because the string actually needs to be
parsed to see if there is a character encoding hiding in there, and
the output writer may need it's encoding changed.
You can see in the changelog
(http://tomcat.apache.org/tomcat-7.0-doc/changelog.html) this entry
under 7.0.33, which I think is the relevant part:
"The HTTP header parser added to address 52811 has been removed..."
Take a look at the references provided if you are interested in the
details. Otherwise, just upgrade to 7.0.40 and try again.
Or is there something platform dependent that I should take care
of?
There could be a bug in one of the JVMs, but this is fairly
well-exercised code that you are talking about.
- -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
