We’ve been discussing this a long time ago already, but somehow it is hard to find out what the best mix is regarding this question: How Many Virtual Servers Should Be Associated with a Single Application Pool? We are running a few SharePoint servers that has many WSS sites (virtual servers) on them. We encountered (and here)and solved some problems regarding this question. Bill English published a very good article about this subject, which can be really usefull:
“First, you need to do some performance monitoring of the process that runs your SharePoint threads. This will be the W3WP processes. You need to *know* how much memory these processes are consuming on average. There will always be spikes and valleys, but the overall average is what you're after.
Secondly, you need to decide if you're going to run the /3GB switch and perhaps the /USERVA switch to allocate more of the 4GB address space to UM, which is where SharePoint runs.
Thirdly, if you've never run SharePoint and are trying to predict the future without any past history, then your best practice here is to guess based on the numbers that Microsoft has provided. What do I think? Well, here's my take on all this, in a nutshell:
-
Do not run more than 10 virtual servers per application pool until you have some performance monitoring experience behind you and you can point to your own numbers which tell you that your app pools can handle more virtual servers
-
Do not plan to run more than 20 virtual servers on a single physical server without adding a second (or more) web server in your farm. The reason I say this is because if you're running 20 virtual servers, you've got a growing, busy farm and chances are good that your best practice will be to scale out before you scale up.
-
Always purchase servers with 4GB of RAM to give yourself maximum flexibility in memory allocation for your application pools. BTW, I also recommend dual proc whenever you can get it. Most are doing this these days, so this is nothing profound.
-
I recommend running a web garden of 2-3 for each application pool. When stsadm runs, it locks one of the threads for it's own use. Having other threads available to service calls during backup/restore operations is necessary in most environments. In addition, if a thread becomes very busy, the other threads can pick up the slack.”
Read the complete article