17 messages in org.apache.tomcat.usersRe: Best Practices Question| From | Sent On | Attachments |
|---|---|---|
| ach...@saysit.com | Sep 29, 2002 1:44 am | |
| ach...@saysit.com | Sep 29, 2002 4:20 am | |
| ach...@saysit.com | Sep 29, 2002 4:23 am | |
| ach...@saysit.com | Sep 29, 2002 4:26 am | |
| Barry Moore | Sep 29, 2002 3:39 pm | |
| V. Cekvenich | Sep 29, 2002 5:31 pm | |
| Kent Perrier | Sep 29, 2002 6:07 pm | |
| Craig R. McClanahan | Sep 29, 2002 6:39 pm | |
| Oskar Bartenstein | Sep 29, 2002 8:30 pm | |
| Craig R. McClanahan | Sep 29, 2002 10:17 pm | |
| Oskar Bartenstein | Sep 30, 2002 1:10 am | |
| Turner, John | Sep 30, 2002 5:35 am | |
| Turner, John | Sep 30, 2002 5:38 am | |
| Step...@bmwfin.com | Sep 30, 2002 5:38 am | |
| Craig R. McClanahan | Sep 30, 2002 9:22 am | |
| Glenn Nielsen | Sep 30, 2002 1:13 pm | |
| Glenn Nielsen | Sep 30, 2002 1:45 pm |
| Subject: | Re: Best Practices Question | |
|---|---|---|
| From: | Glenn Nielsen (gle...@mail.more.net) | |
| Date: | Sep 30, 2002 1:45:14 pm | |
| List: | org.apache.tomcat.users | |
Craig R. McClanahan wrote:
On Sun, 29 Sep 2002 ach...@saysit.com wrote:
Kent, I think we are on the same track , Apache was designed for that purposes , is more robust and mature and certainly has less security related issues.
Regarding maturity, I presume you're talking about 1.3, right? The Apache 2.0 code is quite a lot newer.
The latter comment (less security related issues) has not been true lately, if you watch the security bulletins closely. Although Tomcat just had a security update, the problem was exposure of JSP source code -- substantially less of a dangerous problem than the two recent buffer overflow vulnerabilities that Apache has had (both in the last couple of months).
The previous Tomcat security problem was also a source exposure issue, and was over a year ago. Thanks primarily to the Java programming language, it's pretty difficult to have the kinds of "you can cause the execution of arbitrary code" problems that anything written in C (including Apache's httpd server) can be subject to. No such problem has occurred in Tomcat during the four years I've been involved in it, whereas Apache and its associated modules have had several.
IMHO, anyone who goes to all the extra effort of configuring Apache+Tomcat, instead of Tomcat alone, is nuts unless they need it. Valid reasons to need it include:
* Tomcat standalone is not fast enough (note that this is different from a rule saying select the "fastest possible" solution -- that turns out not to be a requirement in every scenario).
* You need the extra features that Apache provides (such as integration with existing modules).
* You need to run on port 80 in an environment that requires root for this.
* You already know how to configure it, so there's no extra learning curve.
Blindly installing Apache+Tomcat because "that's the thing to do" is a waste of effort in many scenarios.
Blindly using Tomcat to serve static HTTP content for a production system is not "the thing to do" either.
1. Tomcat running within a JVM is much more brittle than Apache. Apache can run for years w/o a problem. I don't think anyone can say the same for Tomcat, I can't. And this isn't necessarily something specific to Tomcat, it is due to the nature of how the JVM works and how well the applications deployed are written and tested. With Apache in front of Tomcat serving static content, if Tomcat fails (and it will) at least your static pages can still be served. I have never gotten a run time with Tomcat of more than four weeks on a production system before it failed, even with Apache serving static content.
2. Tomcat can cause random latency problems handling requests. Whenever
the JVM does garbage collection Tomcat freezes. GC can take only a few
seconds now and then on a well tuned system. But that isn't guaranteed,
sometimes it can take 10's of seconds. Meanwhile requests are stacking up
waiting for Tomcat to serve them. This then causes a cascading effect
significantly
increasing the number of Processors required and load on the system due to
Tomcat.
3. Putting Apache in front to serve static content allows you to take some of
the load
off of Tomcat, letting it do what it does best, dynamic content.
4. If your site gets hit by the SlashDot affect for a dynamically generated page Tomcat could very easily get overloaded, you could temporarily change that page to a static one served by Apache. (I have had to do this) Apache will handle spikes in traffic much better than Tomcat.
5. And if traffic increases you can setup Apache to do load balancing with
multiple
Tomcat instances.
In the end, it all comes down to testing your site prior to putting it in
production
and choosing the architecture best suited for your site. It can be very
difficult to
simulate a production load, and it needs to be done over weeks, not just hours.
Regards,
Glenn