posted by mthomas on April 14, 2010 11:14 PM

The short answer is that this is a myth. The longer answer is that back in the days of Tomcat 3 there was some truth to this depending on circumstances. However, for the versions of Tomcat in use today (5.5.x and 6.0.x) then there is no need to use httpd for purely performance reasons. Tomcat now supports the native/APR connector which uses the same native library (the Apache Portable Runtime—APR) as httpd for the low-level I/O and therefore can achieve similar performance to httpd. When serving static content there is ever so slightly more overhead when using Tomcat compared to httpd but the differences are so small they are unlikely to be noticeable in production systems.

If you research the httpd vs Tomcat performance issue, you will find a variety of load and performance benchmarks that show a range of results. An often quoted result shows that Tomcat's pure Java connector is consistently faster than httpd.

This particular result is the opposite of what is expected. httpd should be significantly faster than Tomcat's pure Java connector. This result is probably caused by the size of the file used. Tomcat caches small static files in memory by default and this will provide a significant performance improvement. httpd does not cache files in memory by default. This demonstrates quite nicely how the definition of the benchmark can have a significant impact on the results.

The performance testing performed by Christopher Schultz, a regular on the Tomcat users mailing list, used a wider range of file sizes and provides – in my view – better results. The results of his tests are shown in the graph below.

These results are much more in line with what is expected, although there are a few interesting points to note:

• Apache httpd and Coyote APR/native show similar performance levels.
• Coyote NIO isn't too far behind httpd and Coyote APR/native.
• There appears to be a limit on the usefulness of sendfile. This may be a hardware limitation but is worthy of further attention. I've added this to my todo list.
• For small file sizes (less than ~10KiB) the static file caching in Tomcat provides a significant performance boost.

The detailed results for any performance test will vary with a number of factors such as the hardware used, the number of concurrent requests, the use of keep-alive and the use of caching. These factors can change the results of a particular test but the broad performance results will remain the same:

• httpd and Coyote APR/native typically have similar performance.
• Coyote NIO is typically just behind Coyote APR/native (further behind for SSL).
• Coyote BIO will typically offer the lowest performance.

The settings to achieve the best performance will vary from application to application. The best settings for an application will depend significantly on the size of the resources, the ratio of static to dynamic content, the number of concurrent users, the usage patterns of those users and so on. Generally, performance can be improved by increasing the cacheMaxSize for the context, increasing the number of connector threads (using maxThreads [4]) available to process requests and enabling keep-alive (using maxKeepAliveRequests) but all of these come at the cost of increased resource usage. There is a trade-off to make here between performance and resource usage that will be different for each application.

It should also be noted that there is no magic "make it run faster" option in Tomcat. If your application takes 15s to generate a request, there is nothing that Tomcat can do to improve that. You'll need to profile your application to understand why requests are taking that long and then tune your application code appropriately.

While raw performance for static content may not be a good reason to use httpd, there are a number of good reasons why you might want to use httpd with Tomcat. The most frequent reason is to provide load-balancing to two or more Tomcat instances. httpd isn't the only option to so this - hardware load balancers or other reverse proxies can be used - but it is a popular choice amongst system administrators as many of them are already familiar with httpd. I'll write more on using httpd as a load-balancer in a future article.

httpd is also used with Tomcat when there is a requirement to support technologies other than Java. While Tomcat can support PHP or Perl, the support for these is better in httpd. Therefore, for sites that need a mix of technologies httpd can be used as the front-end web server, directing requests to mod_php, mod_fastcgi, mod_proxy_http (for Tomcat) or any other module as appropriate.

httpd's support for integrated Windows authentication is also a reason for using httpd in front of Tomcat. There are Tomcat based solutions for integrated windows authentication and, as these gain acceptance through wider use, this particular reason for using httpd may become less important. However, at the moment, it remains one of the more frequently cited reasons for using httpd with Tomcat.

In summary, there are good reasons for using httpd with Tomcat but raw performance for static content isn't one of them. If you are using httpd solely to improve static content performance then I recommend taking a look at the Coyote APR/native connector for Apache Tomcat.

Mark Thomas is a Senior Software Engineer for the SpringSource Division of VMware, Inc. (NYSE: VMW). Mark has been using and developing Tomcat for over six years. He first got involved in the development of Tomcat when he needed better control over the SSL configuration than was available at the time. After fixing that first bug, he started working his way through the remaining Tomcat bugs and is still going. Along the way Mark has become a Tomcat committer and PMC member, volunteered to be the Tomcat 4 & 7 release manager, created the Tomcat security pages, become a member of the ASF and joined the Apache Security Committee. He also helps maintain the ASF's Bugzilla instances. Mark has a MEng in Electronic and Electrical Engineering from the University of Birmingham, United Kingdom.