The demand on popular web sites is sometimes more than can be met by a single web server. When this happens, there are two approaches you can follow: take steps to lighten the load on the server, or share the processing load across several servers. In the latter approach, each different HTTP request can be sent to a different web server, even if the requests come from the same user.
The stateless nature of HTTP permits load balancing, but PHP's session handler undermines it. Sessions maintain variables across several HTTP requests: the variables that are written by one request are retrieved and updated by subsequent requests. By default, PHP stores session variables in files on the web server and, therefore, the web server that begins a session must process all subsequent requests that belong to that session.
If you want the benefits of load balancing with sessions, you need to store session variables in a common area that all your web servers can access. A natural candidate for such storage is your database, because you are already using it in your applications. What's more, storing the sessions in the database tier should lighten the load on your web server, because reading and writing to a database should be much faster than reading and writing disk files.
Taking the trouble to code your own storage solution can pay off substantially on heavily loaded web sites. In many applications, the middle tier?the layer that implements most of the application logic?is the performance bottleneck. By deploying multiple web servers, HTTP load balancing can be achieved and the database server better utilized.
As shown in Figure F-1, moving the session data to the database allows an application to scale horizontally at the middle tier. The web server doesn't have to keep session variables; so more than one web server can be employed to process HTTP requests. The PHP scripts on each web server still implement the application logic, but session variables are retrieved from a central database. However, this isn't an infinitely scalable solution: there's a point at which the performance of the DBMS becomes the bottleneck. Also, allowing multiple web servers to access a central database server requires strategies to control concurrent access, a topic we discuss in Chapter 8.