In old versions of tomcat (like 3.2) you can find the recomendation to serve static content in a apache web server and leave the dynamic content to the tomcat itself. At the new versions of the tomcat docs you cannot find any reference to this practice even at the mod_jk configuration tutorial. So I am wondering.
Is still true that tomcat is not good enough to serve static content? If I change my deploy schema to separate static and dynamic content I will have performance improvement?
You shouldn't consider speed when you choose between Apache httpd and Tomcat.
What is JK (or AJP)?
AJP is a wire protocol. It an optimized version of the HTTP protocol to allow a standalone web server such as Apache to talk to Tomcat. Historically, Apache has been much faster than Tomcat at serving static content. The idea is to let Apache serve the static content when possible, but proxy the request to Tomcat for Tomcat related content.
And
Speed. Apache is faster at serving static content than Tomcat. But unless you have a high traffic site, this point is useless. But in some scenarios, tomcat can be faster than Apache httpd. So benchmark YOUR site. Tomcat can perform at httpd speeds when using the proper connector (APR with sendFile enabled). Speed should not be considered a factor when choosing between Apache httpd and Tomcat
Resources :
Regarding pure speed, I suggest to read the Myth or truth: One should always use Apache httpd in front of Apache Tomcat to improve performance? blog post. Let me quote it partially:
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.
...
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.
...
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.
...
Well worth the read.
That being said, using a web server in front of Tomcat to serve static content will obviously free up more power for dynamic content and is thus my favorite option.
Perhaps a Cache-Control header with a max-age value can be added by a servlet filter in Tomcat for all "/static/*" content. And so if the same clients come back often (Intranet), Tomcat could be enough since static content will be in browsers cache and rarely asked to the server compared to dynamic content.
Moreover Cache-Control for static content could be a good idea for an extended network bandwidth.
(It's just my own experience striving to KISS)
