I suspect that a non-obvious architecture that will offer better throughput than the usual is to use nginx for static content and straight Tomcat for the dynamic. Obviously this has drawbacks too.

Its possible that today mod_proxy performs better than mod_jk. It could also be mis-configuration issue – mod_jk documentation is fragmented and unclear.

mod_jk and mod_proxy really are quite different animals

mod_proxy is straightforward easy to understand and well documented.
mod_jk is substantially harder to grok because the documentation is quite fragmented.
mod_jk has substantial advantages over mod_proxy for complex installations or for applications that with high reliability requirements PROVIDED you are willing to learn the sparsely documented configuration syntax. If you don’t tune the dozen or more settings to match your application then its unlikely that a vanilla configuration will work in all situations. I suspect that less than 10% of installs are actually making effective use of mod_jk.

The big advantage of mod_jk is with reliability.

FOR MANY/MOST PEOPLE mod_proxy is the better choice

13 Scenarios where mod_jk is stronger than mod_proxy:

1. imagine that you have a pool of 4 TomCat instances that you are load balancing over. Now if one of these JVMs hangs with, say, an application deadlock thenm you really don’t want it to receive requests. With mod_jk the worker corresponding to the hung tomcat will be disabled as soon as a timeout triggers and no requests will be forwarded until it is healthy again.

2. if a TomCat dies and is restarted automatically by, say, monit then mod_jk will detect that the persistent connection is dead and will recycle connections.

3. If one of your 4 Tomcat is being beaten on by a batch process and as a result has 80% CPU consumed. WIth mod_proxy this instance will be assigned 1/4 of requests and these requests may back up and give user sa bad experience while three other Tomcats have free resources. mod_jk load balance can consider busyness when balancing

4. If you have HA requirements that trump response time then mod_jk can ping the TomCat and be sure it is healthy before forwarding each request

5. If you have a firewall between your Apache and your Tomcat that is configured to terminate “dead” connections mod_jk can make use of TCP keepalive

6. If your Tomcat receives a request and hangs, what do you want the user to see? mod_jk allows you to define a timeout and return an error to the user quickly rather than make the user wait 90 seconds or more.

7. If mod_jk doesn’t get a response on a socket it might be the Tomcat thread bound to the connector socket. You can configure mod_jk to grab another connection and retry the request

8. If a JSP is being recompiled or a class being deployed live then its possible for tomcat to return a 404 when issued a valid response at the “wrong” time. mod_jk can avoid marking the tomcat as bad.

9. If the application is one that has occasional administrative queries that are very slow then mod_jk can be told to ignore a small number of slow requests without marking the tomcat bad

10. An admin console can used to mark a worker as disabled or stopped so that no requests or no new sessions are directed to that instance. Useful for rolling restarts to mitigate memory leaks, similarly if you know that your app has a memory leak that will cause it to fail after 3 days, and if the app takes ten minutes to startup then mod_jk can be configured to give a new Tomcat N minutes before trying to forward real request.

11. If you have an uber-cluster of 40 Tomcats then you can partition them so that session replacement isn’t a 40 way replication

12. hot standby tomcats can be preinstalled and will be preferentially chosen by mod_jk when a tomcat fails

13. If you have a commercial product than can only run on one tomcat host then you might want all requests of teh form /expensivegraph/plot to be directed to Tomcat 1 an dall other requests to be balanced across the pool. mod_jk supports this.