PHP Session Handling
Sessions are an incredibly important part of many web applications. PHP provides an out of the box solution for handling sessions, but it’s somewhat catered to the traditional, single-server architecture. This doc covers the default session strategy for PHP services and recommend other alternatives. After reading it, you should be familiar with:
- How PHP sessions are handled by default
- Recommended PHP session handling strategies
Default PHP Session Handling
By default, sessions are stored in
/tmp/sessions. This directory is inside of and unique to each web instance. This is done for the sole purpose of providing an out-of-the-box session solution for new apps, but is not ideal. Below are consequences for handling sessions in this way.
Sessions Will Be Cleared on Each Deploy
On deploy, new web instances are created in parallel to your currently running instances. Once code has been deployed to the new instances and they’re verified as operational, all traffic is routed away from the old instances to the new. The old instances are then decommissioned. Because
/tmp/sessions is actually on the instance, all sessions are cleared when the instances gets decommissioned.
Sessions Will Only Work Correctly in Single Instance Services
/tmp/sessions is housed in individual web instances, anytime you have more than one instance in a web service, sessions will not work correctly for your users. Requests to multi-instance services are load-balanced between all instances. A user could create a session on one instance, but their next request may be routed to another instance where their session doesn’t exist. Obviously this would make for a frustrating user experience.
Recommended Session Strategies
You have many different options for handling sessions on Pagoda Box, but here are our recommendations:
Store Sessions in a Data Service
In any multi-instance/distributed environment, creating a single, centralized session store is almost necessity. This makes it possible for multiple web instances to write to and read from a single session store. Caches and/or databases make the best session stores.
Redis is an incredibly fast & efficient key/value store and makes a great session store. While data is stored in RAM, it routinely persists to disk, allowing data to persist between deploys and through process interruptions.
Pros: Very Fast, Persistent Data, Redundancy Option Available
There’s a really simple Boxfile config that will configure your app to store sessions in Redis as long as you’re using native PHP sessions. You can find it in the Redis doc.
Databases can make for decent sessions stores. There are many types of Databases available on Pagoda Box and each has their own strengths and weaknesses, but we won’t go into those here. What makes storing sessions in your database nice is 1. You probably already have a database in your app and 2. You probably already have a good working knowledge of whatever database type you’re using.
Something to consider before storing sessions in your database is how much overhead sessions will place on top of your already running queries and how that will affect the performance of your database.
Pros: Persistent Data, Redundancy Options Available for Most Databases
Cons: May Increase Overhead & Decrease Performance
Use Cookie Sessions
Using cookie sessions removes sessions from your infrastructure altogether and instead, stores sessions in your users’ browsers. These are very handy, but know there are things you need to do to make sure sensitive information stored in cookies is secure. Also know that some people have a great distrust of cookies and have disabled them in their browser.
Pros: No Infrastructure Dependencies
Cons: Some Visitors May Have Cookies Disabled, Possible Security Vulnerabilities
Services We Don’t Recommend for Sessions
Below are a few services we do not recommend using as session stores.
Network storage is, as the name suggests, a network file store. Network latency is inherent in any network filesystem, so performance will be affected. Also, there are currently no redundancy options available for network storage.
Memcached is an in-memory object cache that stores data in RAM. While this makes it incredibly fast, it’s not ideal for sessions. If you ever scale your Memcached instance or if the process is ever interrupted, the RAM gets flushed along with all your sessions. Also, there are no redundancy options available for Memcached.
Table of Contents
- Sessions Will Be Cleared on Each Deploy
- Sessions Will Only Work Correctly in Single Instance Services
If you have any questions, suggestions, or corrections, let us know.