Hi Li,
I don't claim to have half the knowledge of some of the people around
here, but
I read an article about how WalMart upgraded to Java 5. They run WalMart.com
on 100 servers running tomcat. I didn't read anything about clustering
in the article,
however I have got to think that your customer is not bigger than WalMart.

John

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


---------------------------------------------------------------------
To start a new topic, e-mail: users@(protected)
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)