Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <3DC59165.9090606@isisnetworks.net>
Date: Sun, 03 Nov 2002 16:13:09 -0500
From: Ryan Hoegg <rhoegg@isisnetworks.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: Re: Tomcat scalability
References: <OF3075B50F.435845C3-ON85256C66.0069AECB@hyperion.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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

Robert_McDermid@hyperion.com 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>