Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm going to release a website soon, and was thinking of having one database server, and one front-end server (so no load balancing needed yet). But if I add more front-end servers, how would I load balance them so that there is an equal amount of users on each site?

share|improve this question

In general I think of load balancing web servers into two catagories:

Sticky based load balancing:

With this method, clients hit the same web server each time. Examples of this include:

  • IP Based: Clients get sent to the same web server based on their client IP address. A hash of their IP address or table is created and they get sent to the same server based on that.
  • Cookie Based: The load balancer inspects the whole or part of a web cookies and directs clients based on that.

Non-sticky methods:

With these methods, clients are not always sent to the same server. Methods for this include:

  • Round-robin: Each web requests gets sent to web servers in turn.
  • Random algorithms
  • Connection Quantity: Send requests to the server with the least connections.
  • Resource Based: Keep track of the resources on web tiers and attempt to keep the resource utilization even.

Which Type?

The non-sticky methods will tend to be more even in the distribution, but your application might not be capable of working with this sort of method if various things such as sessions are stored locally in a web server. Also, with non-sticky sessions you might end up with a lower cache-hit ratio depending on how your app works.

Hardware and Software:

You can get both hardware and software load balancers. I am a fan of software based load balancers that run on commodity Linux boxes. In particular I recommend HAProxy but you might also consider Nginx.

share|improve this answer

It may sound obvious but you'd use a load-balancer. There are lots of types but essentially you create a virtual IP (VIP) for your service and have it alternate the incoming requests across any number of servers 'behind' it, each with their own IPs. There are lots of mechanisms for deciding which server gets which requests from the most basic 'round-robin' method which simply hands out a request then moves onto the next server in a circular fashion, to very complex ones that look inside the servers to decide which are working and least busy.

Perhaps come back to us with more details of your existing environments and budget and we could help you to narrow down what type to go for.

share|improve this answer

As a specific example of basic load balancing when I moved from 1 to 2 application servers I got a another server setup to run Squid which uses round-robin load-balancing on the 2 servers in addition to adding a caching layer. Once Squid was setup and working it was a simple matter to change the DNS entries for the site to point from the original application to the new Squid server.

In my case Squid was an obvious choice as it added load-balancing and caching and was already supported by the application (MediaWiki) but there are many other software choices. Most web servers (Apache, lighttpd, etc...) can be setup as a simple load balancer though usually a faster serer like nginx is preferred. Then there caching apps like Squid/Varnish and finally more specialized apps like HAProxy, Finally, there are also hardware load balancers but these will be typically more expensive and used in higher traffic/high availability setups.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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