On Mon, Mar 03, 2003 at 11:32:07PM -0600, Haytham Samad wrote:
> I have searched in the mail archive and did not find a comprehansive
> answer to the settings one needs to look for to make sure Tomcat
> scales with an increasing number of users.
You'll probably get more milage out of performance-tuning your
app than out of tweaking tomcat.
I do remember one comment that indicated that using it with
Apache can result in significant performance gains. Obviously, the
more static files you're serving, the more payoff you'll get from
adding Apache for serving them. But running Tomcat side-by-side with
apache is a well-explored problem domain, so it shouldn't be that much
hassle.
You might want to check the conversations on theserverside.com,
jguru, and similar sites.
Having said all of the above, if you do start playing with
performance enhancements (for your app or anything else), make sure
you do it right; get some good books on performance/optimizing, read
up on it. The key points are:
1) Don't. (Until you know you have a performance problem; get
it running, get it running right, THEN worry about getting it
running fast).
Early optimization is the root of much evil (to quote
Donald Knuth).
2) Measure performance - you must start measuring before you do
ANYTHING else, or you're just going to spin your wheels doing
stupid stuff. If any optimization does not significantly
improve measurable performance, back it out (don't clutter
your object model or your code with irrelevant kludges).
3) Profile - once you've started measuring overall performance,
measure detailed performance to figure out where you can
improve things. Don't follow the profiling blindly, though;
algorithmic optimization is usually a much better bet than
spot optimization.
4) OPB is usually the best optimization strategy (Other Peoples'
Brains). Sometimes this involves using a better JVM (I've
heard claims for specialty JVMs being up to 30 times as fast)
or using commercial optimizers like JProbe, OptimizeIt, etc,
or the Sun hotspot optimizing JVM, or better implementations
(database drivers are a particularly ripe area for this).
5) Think. Step back and use your judgement every now and then.
A couple of anecdotes I've heard:
One, the guy spent a day or two optimizing a sort - and then
realized that the data set that would be sorted would NEVER be
more than a hundred or so elements.
Another, they did it all right - measured, profiled, figured
out where the hotspot was (where the application was spending
90% of its time) spent a good solid chunk of time optimizing
it. Then they realized they were optimizing the wait loop.
Steven J. Owens
[EMAIL PROTECTED]
"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." - Me at http://darksleep.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
