Craig R. McClanahan wrote:
>
> On Sun, 29 Sep 2002 [EMAIL PROTECTED] 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
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
