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 <[EMAIL PROTECTED]> wrote: > > 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 [EMAIL PROTECTED] http://www.idealtechs.com
--------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
