Hello Andrew, reading your email, Alan's email and the Mladen email piqued my 
interest because I am currently working on a gig to improve the performance and 
monitoring of two Tomcat instances supporting 3 web applications and one web 
service. I am inclined to agree with Alan. And, did you read the ML replies to 
the Xmx and Xms Subject line emails? I must agree with the ML contributors that 
answered the email named in the previous sentence: baseline test, apply Eden 
parameters to the JVM then monitor the results of the load testing. Once you 
have all your monitoring results including logs the next step is to create a 
new metric by comparing the newly acquired data to your initial baseline test. 
There are very good points made on both sides but I have to believe that Tomcat 
tuning a priori is like trying to predict the weather. In my gig there are too 
many unknowns to resolve: 
(1) this is a legacy system which means differing verions of JDKs, Tomcat 
instances, web apps or web services built with framework versions no longer 
supported e.g. AXIS 1.3. 
(2) Commercial vendors that have taken FOSS and re-packaged it as proprietary 
software and as a result there is no direct support from the vendors for: SLA 
source code or updated binaries that were written in this century.
(3) I know my client wants everything upgraded and migrated if possible when in 
reality I will have to improve the monitoring and performance issues with the 
current servlet containers, web services and network topology as it stands now.

I know the rest of the world is moving away from clustering (horizontal 
scaling) and more toward virtualization (vertical scaling). In my case I will 
have to settle for horizontal scaling and the Tomcat software load balancing. I 
welcome anyone wanting to expound on Tomcat load balancing: say, a comparison 
between Tomcat JK connector load balancing and using an appliance like Big IP.

Like you Andrew I would cheer a <calculated> solution if it existed: just dump 
in the number of nodes, instances, network(s), applications, web services, 
bandwidth and client users and viola! out comes the network diagram with 
annotations. Discussion, suggestions, advice, solutions, rants and raves 
welcomed.

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:
> http://people.apache.org/~mturk/docs/article/ftwai.html
> 
> 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

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to