tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Chaney <>
Subject Re: Tomcat Performance
Date Tue, 29 Jan 2008 15:24:05 GMT
Unfortunately I think it is way more complicated than this.

I think that Mladen Turk's article has a lot of very useful information 
about configuring Tomcat and I congratulate him on putting it together. 
However, I've spent some time recently working on some performance 
issues and I think that for any given installation you must consider a 
number of factors.

These include:

1. The time it takes to prepare the data for delivery.

2. The way available resources are combined in the delivery of this data.

1. The database

Where a database or some other persistence mechanism is involved the
performance of the database can easily overwhelm almost all other 

Is the database local or remote? If local, the time taken transferring 
results from the database to the business layer may not be that 
significant but the cpu time and disk I/O spent running the query will 
immediately reduce the resources available and thus increase the 
response time of web requests.

If remote then it is easy for the database to become a bottleneck for 
requests. Also the time transferring the data over the network becomes 
more significant and it is arithmetically added to the AART unless the 
data can be 'preread' and cached.

How well designed are the queries? Are they subject to issues such as 
badly designed indexes which mean that as the data set grows query 
processing time responds exponentially? Has the object design been 
tested for performance - an ORM solution can save a lot of time in 
development but add significant 'hidden' costs. [Please note, I think 
ORMs are a great idea and always use them where possible but like all 
technology they have their drawbacks!]

2. The mix of the need for resources by the application.

Issues to consider here include:

Are sessions required, and the size of the session. This can also 
significantly impact clustered performance. It may be better to keep 
keys for information in the session and re-read the data rather than 
read data once at the beginning of the session.

What processing is required in the business/web layer to structure the 
information? Is there significant XML processing (which can be very time 
intensive?) Is there significant EL processing on a page (which can be 
much slower than 'raw' java')

My experience is that the only way to really assess the overall 
performance of a system is to instrument the system extensively and then 
monitor it in action. Doing this will sometimes reveal bottlenecks which 
you just didn't consider. Of course even then you must be careful of 
'the Heisenberg effect'.

One final point. In Mladen Turk's example he assumes that the full 
bitrate bandwidth of an Ethernet connection is available for useful 
data. From previous experience I have seen that the overhead of the 
protocol and framing information reduce the 100 Mbps to more like 70 
Mbps which would change his max of 625 concurrent requests to about 440.

Another network related issue is that actually most client 'last hop' 
connections are considerably slower than 100 Mbps. Where TCP/IP is 
involved the thread which is actually writing to the network interface 
will block until the *client* has read all the data and indicated that 
the transmission is successfully completed.

In conclusion I think that if you apply two simple formulae to the 
design of a Tomcat based web application you may be shocked and 
surprised at the actual results unless you have very carefully analysed 
your design and investigated the factors which affect performance.



Andrew Hole wrote:
> Hello
> I read an interesting document from Mladen Turk (with whom I want to speak
> directly, but I don't know direct contact) that there is a formula to
> calculate the number of concurrent request:
> Calculating Load
> When determining the number of Tomcat servers that you will need to satisfy
> the client load, the first and major task is determining the Average
> Application Response Time (hereafter AART). As said before, to satisfy the
> user experience the application has to respond within half of second. The
> content received by the client browser usually triggers couple of physical
> requests to the Web server (e.g. images). The web page usually consists of
> html and image data, so client issues a series of requests, and the time
> that all this gets processed and delivered is called AART. To get most out
> of Tomcat you should limit the number of concurrent requests to 200 per CPU.
> So we can come with the simple formula to calculate the maximum number of
> concurrent connections a physical box can handle:
>                               500
>     Concurrent requests = ( ---------- max 200 ) * Number of CPU's
>                             AART (ms)
> The other thing that you must care is the Network throughput between the Web
> server and Tomcat instances. This introduces a new variable called Average
> Application Response Size (hereafter AARS), that is the number of bytes of
> all context on a web page presented to the user. On a standard 100Mbps
> network card with 8 Bits per Byte, the maximum theoretical throughput is
> 12.5 MBytes.
>                                12500
>     Concurrent requests = ---------------
>                             AARS (KBytes)
> For a 20KB AARS this will give a theoretical maximum of 625 concurrent
> requests. You can add more cards or use faster 1Gbps hardware if need to
> handle more load.
> The formulas above will give you rudimentary estimation of the number of
> Tomcat boxes and CPU's that you will need to handle the desired number of
> concurrent client requests. If you have to deploy the configuration without
> having actual hardware, the closest you can get is to measure the AART on a
> test platform and then compare the hardware vendor Specmarks.
> I would like to launch a discussion on the validity of this formula and, in
> case of inappropriate, to try to get a more accurate formula.
> Thanks a lot
> !DSPAM:479f345936612117114708!

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

View raw message