tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: Tomcat Scalability - Long
Date Thu, 24 Oct 2002 19:42:37 GMT
Hi,

>Does anyone have any solid information about the scalability of Tomcat?
It
>seems very limiting to me, but that is hopefully due to improper

What are you looking for by "solid information"?  ;)  

Here are some details about one of our environments:

An 18-CPU Sun Ultra Enterprise-class server, 4GB RAM on the machine.
About 20 tomcat instances, all 4.x.  Various JVM sizes from very small
to 1GB.  Various amounts of concurrent users, but the biggest JVM does
support hundreds of concurrent users.  Pretty much vanilla tomcat
configuration, except increased (100) number of min and max processors.


We hardly ever have to restart due to emergencies.  We restart monthly
just out of habit and because no app, no server is perfect, and we want
to be safe.

Does that answer your question?  I'd be surprised if it did, because our
apps are likely to be very different, and thus present different stress
characteristics to the server and the underlying JVM.

Do you have load tests in place that simulate user action over a few
days?  Tests that you can run in a test environment that's a copy of
production?


>Tomcat 3.2.4 - contexts *are* reloadable right now

I would update tomcat to the latest stable release.  There have been
many performance improvements and bug fixes.  Stability and scalability
should both be improved, all else being equal.

>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.

There are not huge numbers.

>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.

Perhaps it would be worth your while to turn on more tomcat internal
logging, if you haven't done so already.  I don't know how to do it in
tomcat 3.x, but in 4.x you can get ample information about tomcat's
internal processes by increasing the logging levels for certain
components.

Have you tried using OS-level tools to look for thread locks?  I think
JDK 1.4 also have something (ctrl-break or something like that, when
running from a console) that will show you deadlocks.

>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.

What's your -Xmx setting, if any?  The JVM by default will only allocate
64MB on the heap, plus a bit extra for overhead.  People have complained
in the past the the Linux top and ps outputs regarding memory size are
confusing.

>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?

Hardware can't hurt ;)  But your load doesn't seem that high.

I would say upgrade to the latest tomcat and JVM, if that doesn't pose a
problem for you.  If your app is to the servlet spec, hopefully you
don't have too much work in order to upgrade.

Turn off reloadable="true" unless you need it.  Play with the number of
request processing threads.  But try to do all this after you develop
realistic load tests so that you can test and compare each
configuration, and find the bounds for each one...

Yoav Shapira
Millennium ChemInformatics

Mime
View raw message