tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher K. St. John" <>
Subject Perf. Test Workload: Long Running CPU/mem/etc
Date Thu, 27 Jun 2002 19:14:24 GMT
Pier Fumagalli wrote:
> And not just numbers in terms
> of reqs/sec, but also in comparison to a long-run test with % of CPU time
> used, and IO usage (uptime)...


 I'd like to run some tests along these lines, but they're a major
pain to set up, so it's worth a little up-front discussion of the
methodology. Feedback from someone who's actually experienced the
problems would help define reasonable boundaries for a useful test:

 - How long? Minutes (under high load), hours, days? If, for example,
   the problem is with light load over days, it might be reasonable
   to aproximate it with a heavy load over minutes. I'll be looking
   through the archives and bug lists, but any direct feedback on
   especially problematic areas is appreciated.

 - What sort of load profile? The more specific the better. A single
   URL over and over is easy (and easy to analyze), but a mix is
   more "realistic". Also, static files or just servlets? JSP? etc.
   It's easy to move into the dreaded "general overall test of 
   performance" trap, so maintaining a tight focus is important.

 - Stats? CPU, disk usage, memory, etc. But it gets to be a problem
   to measure all of those things in a way that applies cross-platform,
   so I'd prefer to base the statistics collected on specific problems.
   (Memory usage climbs, so we monitor that, CPU usage goes up, so
   we monitor that).

 There's a bit of a focus issue here, too. I need to be careful
to avoid turning this into a regression test. (A regression load
test would be good, but that's not this) I think you could argue
that "tomcat gets slower over time" is a performance thing, but
"tomcat crashes under heavy load" is just a bug. 

 If there's already a thread on this in the archives, pointers,
keywords, bug#'s, etc. are much appreciated.


Christopher St. John

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

View raw message