Tomcat 6 vs Tomcat 5 performance

In any httpd + Tomcat setups I have worked with, we get rid of any of the HTTP connectors, contain the AJP connector to loopback and let it run without encryption. The goal is to let Tomcat do the Java application work and let httpd handle all of the HTTP services.

The only way the redirectPort would get used in the case of the AJP connector is if there is a web application (web.xml) containing a security-contraint having a user-data-constraint having a transport-guarantee set to CONFIDENTIAL.

At least in our case, it is rare for our applications to have such a construct defined. We typically handle the secure communications via httpd or the load balancer. Most of our applications require SSL at all times anyway due to the data displayed.

Updated response:

Here is a real baseline Tomcat configuration with the slight tweak to increase the connector's maxThreads to 500. It is configured only to listen for AJP/1.3 traffic on loopback (as well as for the shutdown port).

<?xml version='1.0' encoding='utf-8'?>

<Server port="8005" shutdown="SHUTDOWN">
  <Listener className="org.apache.catalina.core.JasperListener" />
  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
  <Service name="Catalina">
    <Connector port="8009" protocol="AJP/1.3" address="127.0.0.1" enableLookups="false" maxThreads="500" />
    <Engine name="Catalina" defaultHost="localhost">
      <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true"
            xmlValidation="false" xmlNamespaceAware="false">
      </Host>
    </Engine>
  </Service>
</Server>

On the httpd side, we have a proxy_ajp.conf file which we use to specifically map URL paths back to the Tomcat. Example:

LoadModule proxy_ajp_module modules/mod_proxy_ajp.so

ProxyPass /fooAppA/ ajp://localhost:8009/fooAppA/
ProxyPass /fooAppB/ ajp://localhost:8009/fooAppB/

ProxyPassReverse /fooAppA/ ajp://localhost:8009/fooAppA/
ProxyPassReverse /fooAppB/ ajp://localhost:8009/fooAppB/

The httpd.conf can be configured to use (and optionally force) SSL. But that is completely optional.

• The drawback of sticky-sessions is that with a growing number of nodes (in the range of > 100, > 1000) the probability of failure increases. Then it's preferable that it doesn't matter which node serves the request. However there are issues that have to be solved with sticky sessions differently, which of course depends on the requirements and the application (examples are session synchronization, preventing double submits, redirect-after-post etc.). Most often my own preference is to use sticky sessions as long there are a limited number of nodes. For 4 nodes personally I'd recommend using sticky sessions.
• We have used sticky-sessions and session replication via memcached-session-manager in production environments. memcached-session-manager was developed during the relaunch of tchibo.de (one of the biggest ecommerce-sites in germance), with the goal of both performance and scalability.
• We chose sticky-sessions for this application
  • because of better performance
  • the customer-requirements opted for sticky-sessions
  • the used web-framework was better suited for sticky-sessions.