tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Crowther <>
Subject RE: Tomcat Performance
Date Tue, 29 Jan 2008 16:12:13 GMT
> From: Alan Chaney []
> Unfortunately I think it is way more complicated than this.


Andrew, you keep mailing this list looking for simple, neat and clean ways of working out
the maximum capability of a Tomcat application.  There aren't any!

The *only* reliable approach is to profile your application, on your target hardware, with
a representative load.  Even then, your answers may change if you scale that hardware - and
the change may be horribly non-linear.  To take a simple example, an application that behaves
well with one front-end server and one database server may degrade with 2 front-end servers
so that the overall throughput and response times are both *worse* than with the single front-end
server, because database lock contention has increased and is delaying request completion
of all requests on both servers.  In general, when a team finds this is the case, there's
much wailing and gnashing of teeth, along with a "but... but... but the world doesn't work
like that!" from the people who've never seen something like it before.

If I recall, you've never told us why you want these numbers.  Are you writing a business
case or business plan?  If so, the section on scaling and hardware costs needs a big health
warning on it:  "These numbers are wild guesses and could be an order of magnitude out, depending
on tiny details of how the system is actually implemented."  If your managers or investers
are experienced, they'll know this anyway - and there's no point hiding it from them.  If
the case for the project turns on how much the hardware is going to cost, you have a much
bigger problem anyway, which is that the return on investment is so marginal that the project
probably *shouldn't* be funded.  And, finally, if the hardware cost is significant, then put
more in the budget for good developers, and extra time for performance tuning.  If the farm
is sufficiently large, better brains are cheaper than more iron.  Many/most "practical" scaling
problems can be reduced or solved completely by finding the badly-written piece of code or
poorly-indexed SQL table that's causing 90% of the problem, and fixing it.

                - Peter
Peter Crowther, Director, Melandra Limited

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message