Why You Should Store Sessions in Redis & Not Shared Writable Storage

We get a lot of support tickets regarding slow and/or inaccessible writable directories. In just about every case, the culprit is the same — sessions. In this post, we’ll explain why storing sessions in writable storage can negatively affect your app’s performance and why Redis is the best alternative for session storage.

Important: By default, sessions are stored to tmp/pagoda/sessions, which is mounted as a shared writable directory. This was done to provide a session store out of the box whenever an app is created. In the near future, shared writable directories will not be created unless specifically defined in the Boxfile and this form of session storage will no longer be the default.

What you should understand about writable storage is that it is network storage provided through a cluster manager. Most file operations such as read, write, create, and delete are passed directly through to underlying storage nodes. In these cases your cluster manager acts as a network router on top of a multi Gb/s network. The overhead is isolated entirely to network throughput, which in most cases, is negligible on a multi-gigabit backbone.

When session_start() is called within the php interpreter, a stat() file operation is called for the sole purpose of determining whether the session file has recently changed. stat() operations force your cluster manager to compare hash checksums with all nodes that may have a copy of that file. This operation will also trigger a self-heal algorithm if your cluster has reason to believe any two nodes are out of sync. While this has little, if any, impact on the underlying storage nodes, the time required for your web process to wait for a stat response can result in serious queuing delays. Multiply this by however many sessions are being created, whether by a surge in traffic or an aggressive bot, and these queueing delays quickly turn into timeouts and/or complete unresponsiveness. A network file system is no place for session storage.

In-memory cache engines, like Memcached or Redis, are better suited to serve the role of a session store in a distributed environment. Out of the box, performance is significantly better and you don’t have to worry about the stat() overhead of a network file-store. Out of the two, we recommend using Redis over Memcached. The performance difference is negligible, but Redis routinely persists to disk, maintaining a certain level of data persistence in the event of an outage. Luckily, configuring your app to use Redis as a native PHP session-store is extremely simple.

Using Redis as a Session-Store on Pagoda Box

To start storing native PHP sessions in Redis, add a Redis component to your app and add the following to your Boxfile:

Note: if you have more than one Redis component in your application, the port will increment up from 6379.

Deploy the changes and and enjoy faster, more stable session storage. It’s really that simple.