tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven J. Owens" <>
Subject Re: Configuration Management, JSP Recompiles, War Files
Date Tue, 09 Nov 2004 01:39:26 GMT
Peter, Yoav, 

     Thanks for the advice.  Now if I could just ask for a leeeeetle
more... :-)

On Mon, Nov 08, 2004 at 01:14:22PM -0000, Peter Crowther wrote:
> > From: Shapira, Yoav [] 
> > One great way to approach production setups for Tomcat is one 
> > webapp per Tomcat instance.
> > Restarts are then quick and easy, and no matter what this one
> > webapp does (OutOfMemoryErrors, malicious code, etc.) it can't
> > affect others you have running around because they're in a
> > different JVM.  The ease of setting up Tomcat standalone makes
> > this not just feasible, but probably recommended over a many
> > webapps per Tomcat instance setup.

     This does sound like a really good argument for using separate
tomcat instances.  My main qualm is what other server infrastructure I
might need to think about (*do* I need to think of any other server
> This approach works well if:
> - the webapps have a memory footprint that is large enough to make the
> JVM overhead irrelevant;

     Any idea what the memory overhead of JVM & tomcat is?  I'm going
to guess that the answer is "not insignificant, but not problematic"
for my current load of a dozen webapps on a 2GB machine (and that RAM
can be fairly easily bumped up - it's only money :-)).
> - the webapps do not have to be run on the same port.
> If you are running hundreds of tiny webapps it might be a bit of
> overkill, and if many of those webapps need to be on (for example) port
> 80 or 8080 then it simply doesn't work.  This said, I agree with Yoav -
> it makes management a whole lot easier and reduces interactions between
> webapps.  I use it wherever I'm principally running services that don't
> need to be exposed via our firewall.

     I'm certainly leaning in this direction.  I'm using apache to
front-end the apps.  Can apache/modjk cope with different ports for
different tomcats for different webapps?

     Thinking about it, I have:

     - apache
     -- modjk
     - tomcat
     -- jdbc driver & DBCP pool
     - mysql

     If I'm going to have multiple tomcat processes, the main things I
would think to worry about (besides sheer disk and memory consumption)
are connections between apache and tomcat, and between tomcat and
mysql.  Apache and Mysql are already handling the current load,
nothing should really change about the database tables or the http

     For modjk, I have no idea what the concerns might be, except to
start with, can modjk even do this, using multiple tomcat servers on
different ports?

     For the jdbc driver and connection pool, the only thing I can
think of is resource consumption of the database connections, mainly
on the mysql server side of the equation.  I should look into how many
database connections mysql is configured to provide, and how using
multiple tomcat instances might affect that.  I'm not sure what the
answers are, but two questions I can think of:

     - The multiple connection pools will definitely mean that there
will be more database connections kept in overall machine memory
(whatever the lower bound is on the DBCP times the number of tomcat
servers) at any one time.  How will this affect mysql?
     - The multiple connection pools mean that the collection of
tomcat servers will have a much higher upper bound of open connections
(normal upper bound times number of tomcat servers).  Is there more of
a risk of swamping the mysql server?  Should I configure mysql to
handle more connections, or should I configure the tomcat DBCP pools
to allow fewer connections?

     These are the kinds of topics that I would love to find covered
in a "best practices for tomcat hosting" guide.  Any recommendations?

Steven J. Owens

"I'm going to make broad, sweeping generalizations and strong,
 declarative statements, because otherwise I'll be here all night and
 this document will be four times longer and much less fun to read.
 Take it all with a grain of salt." -

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message