At my company our main product is web based and each of our customer has their own website. Each customer goes to customer.domain.com to access their website. Currently, in IIS each customer has their own website set up, and are given 1 application pool for all of the applications in that website. Many of our customers are on the same code base, but some customers are on newer versions (beta testers).
We also use load balancing so that each request may hit any of X servers.
Is this the most ideal setup? One of the main issues is that we only have about 8 GB of ram on the server, but also about 200 clients, so for each application pool we have to limit the amount of memory it can use to like 300MB so that we don't run out of memory, but this also causes the app pool to recycle frequently.
We want to scale out, rather than up, but as we add more and more clients, we are going to have less and less RAM available, or we will have to start adding massive amounts of ram to the servers.
If you have a similar setup, how have you solved the problem?
We have several different sites setup on the same box under different domain names for different customers. We are running them from a single folder and a single app pool as they all share a code base.
For customer that want to look at beta code we have a staging site setup as well which they can log into and look at (if accounts have been setup on that site for them) which has a different set of FQDNs. So we end up with two websites and two app pools.
Basically all you need to do is setup IIS to listen on multiple IPs with the certificates setup for each one as needed. This way the data is only cached once.
This is going to depend some on your environment specifically how many servers we're talking about, whether the servers are 64 bit, and how stable the application is.
I see three options:
Advantages: Robust.
Disadvantages: Cost (but ram is getting pretty cheap these days)
Disadvantages: If the application has stability issues, consolidating 200 clients into 2 or 3 application pools is a potential recipe for disaster. If your load balancer can properly detect the availability of the app and apply the state change to all the URLs this risk can be mitigated. Also, if these machines are 32 bit, running 100+ clients in a single app pool may push you dangerously close to process memory limits.
Advantages: Robust, No additional costs (as long as you have enough servers!).
Disadvantages: If you don't have at least 4 servers this is going to an expensive/unattractive option. Also, you introduce new problems like having to track which specific clients are high usage and balancing those across the multiple farms.
The simplest solution is to first move your Beta sites to there own set of servers, second look at ways to break up your current users into groups.
Customer 1, 2, 3, 4 all go on server a, b, c Customer 5, 6, 7, 8 all go on server d, e, f
and so on, this way you have redundancy and your customers are load balanced
if you want to get even more elaborate look into visualization using something like vmware esx so you have 3 servers in a cluster and then build as many web servers as you need, you could even go so far as to create a dedicated virtual server for each customer, but this is more of a scale up to scale out solution