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

If you mean balanced tomcats with session sharing and everything,
dunno, maybe, you should ask people who use it.
Otherwise: sky (or probably other application resources) is your
limit. And a good loadbalancer(s) infront.

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

Again, impossible to tell. If the user have to pay for the usage I'd
expect the ratio to be high, otherwise - very low. It also depends on
the average click interval and average visit duration. For example if
you can run sessionless with a SSO, then the number of concurrent
users is irrelevant.
However, for a free site I would expect the ratio to be something
around 0.5% (if the site is good) for concurrent users and 5-10%
unique users a day.
In your case: 50.000 - 100.000 users daily. 5.000 users concurrently.
Of course only out-of-the-blue estimations :-), for better prediction
you should ask someone @ youtube :-)

regards
Leon

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

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