Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

When is the right time to start adding(or thinking about adding) servers to your Web Application? What are the difficulties involved in going from a single server(DB and Web) to multiple?

For example:

Most of the time you start with one sever that you use for both DB and Web then you split you DB/Web onto a different server then go to multiple web servers(which creates session issues) then possibly a NAS for the DB etc etc.

share

locked by HopelessN00b Dec 5 at 3:01

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

5  
The very limited information you have provided means any answer is largely guesswork. Please define the context in which this is being asked so that answers can be meaningful. –  John Gardeniers Aug 2 '09 at 0:53

7 Answers 7

up vote 10 down vote accepted
+100

When is the right time to start adding(or thinking about adding) servers to your Web Application? ...(going from a single server ... to multiple)

Think about it: From the beginning.

Start adding: When you get your first "server too busy" error. Anything sooner is premature optimization.

(Unless your web app is mission critical, in which case you probably aren't starting from scratch and don't need to poll the serverfault.com community.)

But seriously, for modern consumer web applications, getting "server too busy" can actually be a good thing. It certainly never hurt Facebook, Twitter, or YouTube. The danger with adding servers too early is that your app will never be as popular as you are expecting and you've ended up wasting money that could have been spent on feature development.

If you're one of the lucky few who actually has a hit web property, then (a) congratulations, and (b) you'll be able to measure your average response times from your log files and can take a more metric-driven approach to adding servers.

share
    
Yes! You're right. If you design your environment well, you can scale up to millions of users ;) Have a look at: heroku.com/how/architecture and: highscalability.com The best way to scale is adding ressources when there is a need to. "Adding" Servers is only one way. A few companies sell cpu-time & memory as needed. –  Martin K. Aug 2 '09 at 19:20
1  
think about it - good add when you get server too busy? - too late! (though your point is really when to add the 1st additional server... after that, you should have a clue to how fast you are growing... –  ericslaw Aug 4 '09 at 22:19
    
@ericslaw, good point, based on the OP's question, he's clearly asking about the move from 1->2, but I'll update my answer to make that more clear. –  Portman Aug 5 '09 at 22:52

Personally, I always start with a separate web server from the DB server.

(based on IIS6 and SQL Server)

  1. A database will just chew up resources (RAM, DISK, CPU) and compete with the web server. This can make the web server appear unresponsive and the database "bad"
  2. Security. Not a good idea to have more on the "edge" than you need. Move the DB to inside your DMZ and poke a non-standard hole (not 1433) in your firewall for SQL traffic.
  3. Separation of roles. Now you can see if it's the DB or the IIS or application that's chewing up CPU

However, we do ALL this on a vmware server (3 node cluster in fact), and the webserver and the db server only have 1 vCPU and 1GB RAM. And they support a fairly busy suite of websites (external and intranet) without too much sweat.

But I know if I get a surge of popularity (and it might happen one day!) I can quickly reconfigure the vm's with more RAM and CPU.

On a practical note: Monitor your performance over time. Track changes and be proactive.

share

When is the right time to start adding(or thinking about adding) servers to your Web Application?

When you are designing your application. I've seen too many applications not designed to use multiple servers, and reverse engineering that later can be horrendous.

Make sure you test on multiple servers, too. Again. I've seen many applications work fine in dev/test only to fail in production because they couldn't deal with load balancers, or firewalls, multicasting hadn't been considered etc, etc.

And the time to add another server is when your capacity management statistics suggest that you will run out of capacity in just over the time it will take you to add another server.

You are collecting cpacity statistics? No? Then another thing to talk about with your application developers and infrastructure management people.

I disagree that waiting until you actually get 'server too busy' and irritating your users is the correct thing to do. Adding a new server to a production environment can be a lengthy process, and waiting until you have errors before you start is not really wise.

share
    
I've personally witnessed at least 30 companies that have too many servers, and only one that had too few. If you have capacity stats, then your answer is 100% correct. But in the absence of detailed capacity stats, I think "server too busy" is a good rubric. –  Portman Apr 30 '09 at 14:29
    
You also have to consider the costs of having too few against having too many. Too many wastes money, but irritating your users isn't free either. –  Paul Apr 30 '09 at 14:43

As others have mentioned, the question is vague, but there's really a pretty simple answer to it:

You need to add another server when limitations on the current one start costing you money.

If you're offing a free service, then there's really no incentive to add additional servers.

If you're making money off your service, then you can do a cost/benefit analysis: how will additional servers improve performance, and how much more profit will result?

share
    
+1 for giving a business answer to what is actually more of a business question than a technical one. –  Portman Aug 5 '09 at 22:57
    
Thanks. If only you knew how ironic your handle was. –  chris Aug 6 '09 at 0:26

One of the things you should do is load test your existing one-server application to see how many sessions and users it can support at once. Once you know that, you can monitor those same metrics over time. When your numbers begin to approach the known limits, it's time to start preparing new hardware for deployment. You will need to consider the lead time for additional servers so that you can deploy before the existing system reaches its limit. This is a very general overview, and the details are covered very well in the book "The Art of Capacity Planning" by John Allspaw.

Having said that, I would break the database server and web server into their own systems as a starting point, then load test each to determine the theoretical load. Usually the web server will become the bottleneck first, so your application should be written with scalability in mind. The question mentions sessions, and depending on the platform you're using there are several ways to share sessions between servers, store them in the central database, or use load balancing hardware that will direct the same user to the same server unless it becomes unavailable for some reason.

But to answer the core question "when do we know when to do it," that will be all about the metrics you're collecting and comparing them against known limits arrived at through load testing.

share

Without any further information on what your application is, it's hard to give any specific advice, but here's some slides from a 2005 presentation by Brad Fitzpatrick on LiveJournal's infrastructure (with a heavy emphasis on database load balancing):

http://www.scribd.com/doc/2684169/LiveJournal-scaling

share
    
Brad's presentation is a classic on Web based app scaling. It's 4 years old now though, so be aware of some "oldie" stuff. –  Francisco Aug 2 '09 at 21:11

In general, going from one to multiple front-ends is trickier than separating the front-end from the (usually database) back-end. However, careful use of load-balancers and "sticky" sessions can make this transition easier.

As for "when", the key to finding that is to measure the performance of your web (and database) server(s). Ideally in a test bench with realistic traffic-load, then see where the performance dips into "not good enough". Once the load on the live site starts getting close to the "not good enough", you order a new front-end.

If you know roughly when you'll be needing a new server and roughly how traffic volume grows over time, you can aim at having the new server deployed just before it's needed. Unfortunately, I can't give you any hard figures, as these things are very dependent on the specifics of your set-up.

share

Not the answer you're looking for? Browse other questions tagged or ask your own question.