So you've finished your largest project yet, a robust order-taking system for a very successful company.  To give the best user experience possible, you made heavy use of sessions in order to keep information about the customer handy, from page to page, as any good PHP programmer would.  You deliver the site to your customer and it goes live, to great fanfare.  Traffic is slow at first, but as the customers begin to use it, traffic picks up and in a few months the site is serving over 5 million hits a day, between shoppers, search engines, and actual customers.  The web server is dying under the stress, and the company turns to you to figure out how to increase their bandwidth.

A quick analysis of the database shows you that its usage is quite low.  It's the actual load on the web server that's causing the issue.  Your code is tight and uses caching where available (as is obvious by the low load on the database).  The problem seems to be the sheer traffic on your web server.  How do you cope?

The above problem is one we should all be so lucky to face: being overly popular.  If your website is as wildly successful as the one in the above example, it means you should have the resources available to address this kind of issue.

And just how do you fix this problem?  In our example, let's address the problem by adding web server(s).  It doesn't matter if you round-robin them, or add them to a true load balancer.  But adding additional servers will allow the load to be split among more than one machine, allowing each of them to serve data in a more efficient fashion.

This will solve the immediate load problem.  But what will it do to your application?

For those of you who use sessions but have never written an application for multi-server distribution, you may be surprised to know that your sessions will fail miserably if left alone.  Why is that?