لطفا منتظر باشید ...
F.1 Using a Database to Keep State
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 tierthe layer that implements most of the application
logicis 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.
Figure F-1. Three-tier architecture using a database to store session variables
