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
ryan
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
a> cc:
Subject: Tomcat scalability
03/11/2002 02:39
AM
Please respond to
"Tomcat
Developers List"
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
>
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
