One good rule of thumb is not to solve problems that don't exist. Your first task is to set up a server and hit it with something a good 20%-50% more demanding than your expected load. There exist several automated tools to do this. One is JMeter at http://jakarta.apache.org/jmeter/index.html .

Then, have a look at your actual performance and work on the bottlenecks that arise. If your application is spending most of its time waiting for database results, cache them. If your application is spending most of its time creating and destroying objects, consider pooling. If your app is choking on serving up 1600 images a second, use a web server such as Apache in front of Tomcat. That will help with static requests (images, static HTML) even with a single Tomcat server doing the servlet work.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

[EMAIL PROTECTED] wrote:

That's a tough question to answer, and pretty much the only way you're
going to be able to tell is to try it. Here's a few
suggestions of things to think about:

The first question you might want to ask is can your database handle 1600
transactions per second? If not (and even if
it can) you may want to consider whether some kind of caching could help
you if the data is largely static. This could
be caching of the data itself, or something as simple as caching the pages
themselves, with some scheme to flush
the cache if the data changes. If your data is not very static, then this
wouldn't be as helpful of course.

If it's possible on the OS you are using, I'd be tempted to run 4 copies of
Tomcat, and dedicate a processor to each
one. It's a lot harder to write code that will run reliably on a MP
machine than on a SP one, and it seems that Tomcat has
a few issues in that regard.

Also, remember, it's unlikely you'll ever have that many threads open at
once - if you are actually handling 1600 requests/second
then each request is, on average, taking less than a millisecond to
complete, so you won't have too many overlapping
requests. If you can work out how long it takes to process one request,
then you'll have a best-case scenario of how
many you can handle. In practice, it will be less of course, due to
overhead in handling multiple requests at once.

-- Rob


1. For a project my company is working on we have transactions
requirements of 1600 transactions per second. The transactions consists
of processing a servlet in Tomcat, doing a database call and then
displaying the results to the user so the effective number of transactions
Tomcat has to process is actually greater than 1600.

Can Tomcat cope with 1600 requests in a second(a 4 processor Sunfire
machine will be used)?

Based upon our current application architecture(our java application has
tomcat running inside it), 1600 request per second means we may have
1600 threads open simultaneously.

2. From one article I read at linux journal, Tomcat 3 didn't scale very
well with multiple processors because of JVM issues.


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>

Reply via email to