This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
I've been experiencing trouble after migrating our company's web application from Tomcat 5 to Tomcat 7. There's a significant slowdown with https connections after the migration.
I'm aware that application has a flaw - there's a large number of http request needed for generating a page (> 100 requests), but these are mainly static content (css, js, images etc.) and only very limited (1-3) ammount of requests are for dynamically generated content.
I've just tested the page generation time via local network (and browser's cache off) and the page is being fully loaded in circa 2 seconds (with Firebug on) when using http, while loading the same page using secure connection took as much as 10 times longer. It's extremely weird for me, since I haven't noticed any significant differences between Tomcat 5 and 7 approaches to SSL and the server.xml file is pretty much the same.
Problems associated with server load, heavy user traffic or JVM params are rather not an option here. The memory and CPU usage constantly stays lower than with Tomcat 5.
Here are crucial parts of our server.xml file:
Well, except for defining global thread pool nothing really changed between our versions' configuration. I've experimented with Java Nio Blocking Connector, but haven't noticed any significant improvement. Also can't use APR Connector, because it's some kind of requirement that we must use keystore files we already have.
Any ideas on how to improve SSL performance and what could possibly go wrong?
Sorry for my English, for I'm not a native speaker .
did you try with less number of threads (say 50), minSpare (25) and prestartminSpareThreads=false in executor?
Joined: May 04, 2011
No, can't see why it should affect SSL performance.
More threads avaliable, more requests can be handled and prestartminSpareThreads=true is an improvement, as thread pool is filled with (in this case) large portion of avaliable threads at the start of Tomcat. In case of larger page traffic, Tomcat can save time associated with creating new threads to handle requests, at cost of maintaining the these (300) threads at all times. Moreover, both http and https connectors share same thread pool...
Joined: May 04, 2011
you mentioned that your 5's server.xml and 7's server.xml look pretty much the same with respect to ssl. executor is the only big difference. so, test it and see if it can be ruled out. it should not take more than few minutes to do it. there is no need to depend on guess work when something can be tested very quickly.
more threads do not always mean more performance in practice.