> From: Alan Chaney [mailto:[EMAIL PROTECTED]
> Unfortunately I think it is way more complicated than this.
Seconded.
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: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
