tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: Tomcat stability issues
Date Fri, 01 Sep 2000 06:26:50 GMT
Doug Ahmann wrote:

>
> I have to admit I've never looked at the static file pipeline in Tomcat, but
> I suspect it should be fairly well designed. Given that its written in Java,
> and a little less mature, I'm sure it can't touch Apache's speed. But the
> actual transferring of content bytes will probably be the bulk of the
> transaction, and that will be native vm code anyway, so I wonder what the
> differential for a static file transaction is?
>

A small amount of testing on this issue has been done while evaluating a feature
that is implemented in the Tomcat 4.0 code base -- you can configure a cache of
the static files in your app, so that the Java code only has to load it once.
For static resources that have been so cached, Tomcat 4.0 can serve them
essentially as fast as Apache can.

This works great in an environment where your app is primarily dynamic, but you
have a relatively small number of accesses to static resources.  It doesn't help
you at all if you have huge amounts of static content -- actually, running
behind Apache is still faster whenever you have more static content than you can
afford to cache in memory (although the gap is getting narrower).

Fortunately, it is very easy to build your apps so that they will run either
way.  My bottom line advice:  try it both ways, and pick the way that works best
for *your* application.  Don't obsess over artificial benchmarks, unless they
accurately represent the workload that your application will require.  Under
most circumstances, the only thing a "hello, world" benchmark tells you is how
fast your server can say "hello, world".  :-)

Craig McClanahan


>
> Charles Forsythe brought up some scaling and security issues. Charles, I
> think things like the Cisco Local Director can be configured to only allow a
> single port to go through, so I don't see how it opens up any more security
> holes to have Tomcat listening on 80 vs. Apache listening on 80. (I'm being
> devils advocate, of course) A hacker could enter full servlet URIs to try to
> run a particular servlet directly, but JServ won't prevent that sort of
> thing, since it just passes everything through. JServ doesn't have any more
> configuration options that Tomcat. So I'm still puzzled as to what the
> advantage is for security, other than SSL.
>
> As for scaling, Local Director (and other products like it I suspect) can be
> configured to make a connection "sticky" to a particular machine, if your
> app depends on it. IOW, if you are relying on the session, then you can
> configure it so that all traffic from a particular user is routed back to
> the machine the user was first connected to.
>
> So if I'm understanding Charles correctly, you're saying that if your app is
> heavy on static content, then it makes sense to have Apache at the front
> end. At my previous company, we had a plan to have an independent image
> server (images.time4.com for instance). Wouldn't that handle what you're
> talking about?
>
> It seems to me that if the bulk of your site is jsp and servlets, there is
> little to gain by having Apache on the front end.
>
> IOW, I'm still not convinced. ;-) Does anybody else have any more insight?
>
> Thanks,
> Doug
>
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Mail - Free email you can access from anywhere!
> > http://mail.yahoo.com/

--
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat



Mime
View raw message