Java Mailing List Archive

http://www.junlu.com/

Home » Home (12/2007) » Apache Tomcat »

Re: Peak load of Tomcat-powered server(s)?

Li Ma

2006-12-26

Replies:

Thank you all for all the answers and suggestions. Here're what I have got
so far from you guys:
1. There's no way to tell a number, because there're too may factors that
will definitely influence my mileage.
  Hehehe, I have expected this number. So I especially appreciate those
who did put some numbers in their reply.
2. I need to do load test to know how far I can go. Yes, I think I will.

Anyway, thank you, everybody, for your nice answers so far, especially in a
holiday period.

Now comes other questions I want to ask:
1. I was told Tomcat can only run max 3 nodes in cluster smoothly. What's
your milage?
2. This is not related to Tomcat, but if a site has N registered users, what
is the average percentage of concurrent user should I expect? I ask this
because my client wants 1million registered users. But he wants me to
support 20% concurrent users, which I believe is way impossible! But I need
to have some number to give him the right sense. This is also important for
me to setup the target.

Thanks again!

Li

On 12/26/06, Christopher Schultz <chris@(protected):
>
> Li Ma wrote:
> > Actually you can imagine the server serves a site like mySpace where
> people
> > can access their own home, blog, images, forum, etc.
>
> It's always different. If your disk array is different from someone
> else's, the answer will be different. If you are using 100baseT instead
> of gigabit, the answer will be different. If you have different speed
> memory, or better or slower motherboards, the answer will be different.
>
> What you really have to do is load test the environment. There is simply
> no substitute for load testing on equipment and deployment layout
> exactly matching your production environment. If you don't do this, you
> will fail.
>
> > Another question, how many threads do you think Tomcat can have on one
> > machine?
>
> That depends on the number and type of CPUs (x86 is not very specific),
> the amount of memory, and how much "work" each thread is doing. For
> instance, you can create tons of threads that never get used, and it
> will only hurt your memory usage (but will be totally worthless). If you
> enable 500 threads, but only use 100 of them, is it worth having 500?
> Probably not.
>
> > And will increasing number of threads help processing more
> > requests? I think 100-150 per server per second is not a good number.
>
> No. Your servers will be bounded by a performance number that can only
> be determined empirically, given target (peak) load and observations
> from production.
>
> > But if it is true, does that mean Tomcat is not suitable for large
> > website? And what does commercial products like WebLogic can normally
> > do?
>
> Wow. Haven't we just gone over the "is TC okay for big website use?"
> question? Short answer: yes, TC will do just fine. Long answer: any
> dumbass can make anything go slow.
>
> A better question (for yourself) would be "how much load do I need to
> handle?" Do you have any target performance stats? How about a sense of
> the "cost" of the average request (usually measured in weighted database
> operations; SELECT is faster than INSERT or UPDATE, for instance)? Do
> you do any heavy operations such as XSLT? How about any other network
> operations such as RMI or anything like that? If you can get away with a
> one-box wonder, DO IT -- at least to start. It's the fastest solution
> per rack unit that can really achieve.
>
> Once you have performance targets, you can start to load test your
> setup. If you can meet your targets, you are done. Otherwise, start
> buying more hardware and scaling your app both horizontally (more app
> servers) and vertically (more physical tiers). Another course of action
> is to try to trim your app a bit if you are /almost/ hitting your
> targets. If it's a matter of a couple of % off of your target, then you
> might be able to make it up by streamlining an algorithm, optimizing
> your SQL queries, or adding an index or something to your tables. Often,
> Java and/or your app isn't the problem... it's your (poorly
> designed/configured/maintained) database.
>
> Good luck with ... all that.
>
> -chris
>
>
>
>
>


--
Li Ma
lima01@(protected)
http://www.idealtechs.com
©2008 junlu.com - Jax Systems, LLC, U.S.A.