Hello Peter, Wow! this is good stuff: exactly what I needed. I feel sorry for the client when they see that first baseline! Thank you! David.
Peter Lin wrote .. > from past experience, it's much better to use hardware load balancing. At a > previous job, we had any where from 12-24 servers load balanced behind a > cisco local director. > > Any load balancing router today can do the job, it doesn't have to be > cisco. What I did in the past was to take production logs and run them in > jmeter against a cluster of tomcat servers. All the servers were behind the > load balancer. > > After the test was run, we collected the logs to make sure the load was > distributed evenly and we generated reports. From those reports, we compared > the results of the new system against the system we were replacing. > > That established the baseline performance for untuned tomcat. I then spent a > week going through 10 different jvm settings and running a full set of > benchmarks on each. At the end I looked at what concurrent loads the entire > system needed to support and chose the settings that match those needs. In > my test suite, I varied the number of concurrent connections, think time > between requests, ramp up time and a mix of requests. > > the key to tuning the system correctly is understanding exactly what kind of > traffic you expect. of course that isn't always possible, so you might have > to take a guess. > > peter > > On 1/30/08, David Brown <[EMAIL PROTECTED]> wrote: > > > > 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] > > > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
