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] > >
