tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: Tomcat Scalability - Long
Date Fri, 25 Oct 2002 14:20:15 GMT
I have the following in production:

Tomcat 4.1, JDK 1.3.1, and MySQL on a Dual CPU Sun 250 app server and Apache
using mod_jk 1.2 on a separate server. We are now getting 4 weeks continuous uptime.
I stop and restart Tomcat once each month because the minimum memory the java heap
uses over time increases.  This is on a site handling 30k Tomcat requests per day.
With peak loads of 5k-6k Tomcat requests per hour.

When scaling Tomcat there are many issues to address when tuning performance.

I would suggest learning more about how the JVM does garbage collection and
test different Java startup args related to jvm stack size, etc.  Try starting
Tomcat with the java arg "-verbose:gc", this will collect GC data which can
help you when tuning the JVM memory usage.

You might also want to profile your applicaiton using OptimizeIt or JProbe
to see if it is the source of the problem.

And of course the performance tuning should be done on test servers which
are as close as possible to your production environment and with a load
that simulates your site usage.

Consider upgrading to Tomcat 4.1.  Especially if your site uses JSP.
Jasper 2 which comes with Tocmat 4.1 significantly improves performance
of JSP.

One final note, I would not set reloadable=true on a production system.
That adds alot of overhead.  The reloadable option is really there only
to make development easier.



Brandon Cruz wrote:
> Does anyone have any solid information about the scalability of Tomcat?  It
> seems very limiting to me, but that is hopefully due to improper
> configuration.  Here is our situation and what seems to be happening under a
> small amount of stress.
> ---About our Environment---
> PIII 1.0Ghz
> 512 Meg Ram
> Linux RedHat 7.1
> MySQL Database
> Apache 1.3.x
> mod_jk - logging turned all the way down
> Tomcat 3.2.4 - contexts *are* reloadable right now
> SUN JDK 1.3.1_01
> ---About our Application---
> Our Application is a content management tool that reads and writes to the
> MySQL Database and reads and writes files.  All the pages within this
> application are served by Tomcat 3.2.4.  About 80-120 people per day log
> into this application and spend anywhere from 10 minutes to one hour working
> on the application.  At any given time there are between 15 and 50 active
> database connections.
> ---What we are seeing---
> Tomcat needs to be restarted every few days.  If we don't restart it, it
> seems tomcat eventually locks up and does not respond at all.  No errors or
> anything are reported, it just will not respond.  Apache continues to work
> during this time and all static HTML pages are accessible.
> CPU - The processor usage seems to slowly increase as time goes on.  After
> about one day, it seems one java process uses 30% of available CPU or more,
> depending on whether users are performing operations or not.  When nobody is
> doing anything, the processer still seems to be sitting around 30% until
> tomcat is restarted.  This seems to cap after three to five days and not
> increase too much more.
> RAM - This slowly increases and never stops increasing.  We do not have any
> special parameters set for the VM when it starts, but this does not seem to
> matter.  The RAM gets up to about 135 MB after four or five days, but would
> continue to grow if tomcat were not allowed.
> Can anyone explain this behavior, talk about the scalability of Tomcat, or
> provide any similar working solutions that perform better than this?  Is it
> normal, should we just throw more hardware at it?  Are there configuration
> parameters that can be used to increase performance, such as set
> reloadable=false in all contexts?  Would we get better performance if we
> upgraded to 4.x, or would that just be more work for little improvement?
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message