> 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]