Chris, I am setting previously running Tomcat 6 performance data as a benchmark. And I am straight forward comparing the results with Tomcat 7 to the previous results. I expect a similar performance,if not better.
Actually,the max no. of connections in my case are configurable from a GUI with a maximum of 1000 that a user can set. Hence 1000 max threads would be my peak load case. Well for now I have completely dropped my application out of the scope. I am testing and comparing Tomcat 6 and 7 on the same servers with sample HTML pages. Next in line would be Tomcat 6.0.37 and 7.0.40. I would have to upgrade to minor version of Tomcat 6 otherwise. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRnM+NAAoJEBzwKT+lPKRYDo4P/2LGsApJTBj39lPKdshAYXba DwDWIllFM+fn/XRLsx2fTinBLPupWoGbGrPoVOA7xTTqrJVddJCfwbbmiS2RvcB5 kPMNn+baAWMN3f4z/5fVkXwVhuyfRNKMFNzL64N3hjuqhzMqQGBvoaUbKMq27bzt VzQiLiEC5mUJ4VsnUj+h4yWCFPv2JT7Q4tifneAX3F3ouOI6KqJ7y30LX2qz4xPp 4f/KDgQwMTxrsdDe2R3+dmBFZgo2sHuZZUggGCvTADmjAaPgikAWAO5Yov2tPVhf ZRLrn6s6VAQpRDPN6jNQbogWWw/zakDf8zPrTSjr/BQRrhF7+eRyr3/jWlA9UOkd rs/WIXm6URZjhbzdO7h0qkPOziSw9cekUt/cVUigd9N+Mgyp0YcDw8wtg6Hx0PJC Ig/nvuOB3ePxP01EPc0hXg3fw6GlwTSS0H5GRox0n5cvR83lDtGrzCvqZe+py6z4 JaKtA7FhcYcZrqZiiGMNVYsMcBL5CEr4gQztCbQscfltnTjCIQoM7BclQ+VMHDQI SfLEsMfNBix6ap88H335RAyGUyMbz1kWMtBv7+GvzEoBQ6GDfk39iDu2rLfFLiMi calZtW9asdFFQwpe87hdadPToOgFuyyAIm7EZpSWF69kh5nM6DXSEBGOhjCrc9OB QGR+cvRCWYnodpC4YZhm =NxRr -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
