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 have a question regarding Load Sharing for large websites.

My Understanding:

So if you have a website that has millions of fits a day you will need to have an architecture that can support this sort of pressure. You can either do one or two things:

  1. Invest in a single large server that has huge amounts of processing power, memory and storage (such as Microsoft's TerraServer).
  2. Spread the load of your website across a number of machines.

Let me tackle the second approach, so you have a collection of machines all running Web Server Software and all having access to identical copies of the websites pages. You can either spread the load across these machines using a cyclic pattern in a DNS or you can use a Load Ballancing Switch.

The advantages of this approach is: - Redundancy - servers can fail and the others would "pick up the slack" - Incremental - the ability to easily add new machines to this set-up.

My Question's

  • Is there a Virtual approach to this issue of load balancing now?
  • If the website runs from a database - is there still only a single copy of the database?
  • If a user had a session running on one Server (e.g. they had gone to and had been assigned to Server 2 - were they had created a session) if they refreshed the website (and were allocated Server 3) would they still have their session?
  • What are the other disadvantages associated with Load Balancing?
share|improve this question

migrated from Jan 14 '11 at 15:33

This question came from our site for professional and enthusiast programmers.

You prolly need to seperate this out into individual questions to get a decent answer. Also some of the points reek of spoonfeeding, you might do better to read up on load balancing first and ask questions about the parts you don't understand than try and lump it all together. – JamesRyan Jan 14 '11 at 16:12
Why do you think Microsoft's TerraServer runs off one server? – ceejayoz Oct 10 '12 at 21:53

Unless your application requires a large amount of processing power, it is quite likely that you will run out of network bandwidth before that. This has two consequences:

  • Option 1 is not really an option, as this is not the bottleneck
  • You want to distribute across sites, not across servers.

A load-balancing switch is most useful in a scenario where the processing takes up most of the request processing and synchronisation is not important, for example when building a search engine (the query is complex, the data set is not modified so the individual server can work on a private copy, and it is completely acceptable to operate on data that is several hours old).

For applications requiring logins, you might want a separate infrastructure for tracking users and sessions that can react quicker than that, for example a replicated database containing user data and credential information, and a separate service that can establish the validity of a session ID.

A possible implementation would be to generate the session ID cookie by digitally signing the user ID, the ID of the server handing out the cookie and a timestamp when the credentials have been accepted; individual front-end servers could then contact the login server to query the validity of the cookie (in a real-world scenario, you might want to have some optimizations there).

Shared data sets are difficult to manage, and the answer how to implement this best would be highly dependent on the application in question; this would be a longer article.

Virtualisation helps when hardware is underused or needs to be replaced quickly. It's not that relevant for load balancing, but certainly is one of the tools you'd employ for the individual servers your service is distributed across.

share|improve this answer

Your Answer


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