Myth or truth: One should always use Apache httpd in front of Apache Tomcat to improve performance?
http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-always-use-apache-httpd-front-apache-tomcat-improve-perform
원문은 : 위 링크
Apache-Tomcat과 httpd의 핵심 개발자들이 직접 작성한 내용입니다. 오늘 옆팀에서 Apache만 붙이면 성능이 떨어진다고 해서 좀 봐주다가 찾은 자료네요. PHP를 서비스 하거나, 기타 Apahce의 특정 모듈기능을 필요하지 않는다면, 다시 말해 단순 정적인 웹서비스에서는 굳이 httpd서버를 Tomcat앞단에 둘필요는 없을듯 합니다. 흔히들 대부분의 개발자들이 기본적인 HTTP요청은 Apache가 처리하고 Tomcat내에서 처리될 자바 어플리케이션만 Tocmat으로 보내 처리되도록 하는게 가장 성능이 좋을것이라 믿어 왔지만. 구조상으로 봐도, 더 좋을리는........ Tomcat의 Apache Native Module성능이 httpd에 비교해 전혀 차이가 없는데..........(PHP등을 사용한다면, Apache가 앞단에 있어야 하니, 그런 부분은 논외 처리. 번거로움없이 일반유저로 80포트를 사용하고 싶다거나, Tomcat에러페이지를 관리 하고 싶다거나, 등등 나름대로 Apache를 앞단에 두어야 할 이유도 충분히 있다. 이글의 요점은 Apache를 앞단에 두어서는 안된다~가 아니니 오해 없기를~)
Myth or truth: One should always use Apache httpd in front of Apache Tomcat to improve performance?
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.
'OS > Linux' 카테고리의 다른 글
| Scientific Linux (instead of CentOS 6) (0) | 2011.04.29 |
|---|---|
| [메모] 정규식 표현 (Regular Expression) (0) | 2011.04.06 |
| [FrameOS-6] 가상화/자동화에 안성맞춤 Linux OS (CentOS6/RHEL6????) (3) | 2011.04.05 |
| CentOS 5.x 최신 커널(2.6.38) 컴파일후, 부팅 실패 (0) | 2011.03.21 |
| 기대만빵인 CentOS 6 !!!!!!!!! (0) | 2011.02.23 |
Comments
Configuring Response Headers
We're currently using Apache Httpd to handle such things as expires by type and gzip configuration. I wonder if these things can be set up in tomcat, thereby eliminating the httpd layer for us.
CDN & Throughput
I think that it is useful to use the httpd when you are configuring the Content Delivery Network.
IMHO if you use both the httpd and tomcat on different machines, each can fully concentrate only on its work. Tomcat's threads can compute your application's logic and use the whole memory for speed up the application. Whilst httpd's threads can serve the content from the disk. This can improve the throughput.
-- tom
Different Myth(?)
While this post answers the myth question of native HTTP vs Tomcat HTTP, if you are using a native HTTP to do (perhaps) other services, I'm curious about whether it's myth or truth that one should go with AJP or HTTP for the native<->Tomcat communication. The tomcat documentation mostly seems to suggest that this should be AJP rather than HTTP - is this still just a myth?