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
signature.asc
Description: OpenPGP digital signature
