Existing Session Storage Engines

There is a multitude of session save handlers available for PHP, each with its own advantages and disadvantages. Given the modular nature of session storage in PHP, users are free to create additional save handlers, either as C/C++ extensions, or by using user-space PHP code.
The following list covers some of the more widely used session handlers, and overviews their capabilities:
The ‘files’ save handler is PHP’s default save handler. It stores session data as files on disk, in a specified directory (or sometimes in a tree of directories). Usually, this save handler is capable of easily handling tens of thousands of sessions.
The biggest disadvantage of the files save handler is that it imposes a major scalability bottleneck when trying to scale an application to run on more than one server.
In most clusters, requests from the same users may end up on any of the servers in the cluster. If the session information only exists locally on one of the servers, requests ending on other servers will simply create a new session for the same user, resulting in data loss or inconsistency.
One way to work around this problem may be to store session data on a shared file system such as NFS (Network File System). Unfortunately, this is a highly inefficient method and usually results in performance problems and data corruption. This is due to the fact that NFS was not designed for the high read/write ratio and potential concurrency levels required for session handling.
Another potential solution is to use a “sticky”, session aware load balancer. Most load balancers today have stickiness capabilities in some form or another. While this is a better solution, experience shows that in high loads sticky load balancers tend to become a bottleneck, and cause uneven load distribution. Indeed, most heavy PHP users prefer to use round-robin load balancing with other session storage mechanisms.
In addition, sticky load balancing does not solve another inherit disadvantage of the files session handler: session redundancy. Many users rely on clustering for application high-availability. However, in many cases session high-availability is also important. If a server crashes or otherwise becomes unavailable, the load balancer will route the request to a different server. The application in this case will still be available – but the session data will be lost, which in many cases may lead to business loss.