Drupal Session Handler: everything you need to know

Drupal Session Handler: everything you need to know

Piece of Cake

In this article we compare and benchmark different available session handlers in Drupal, that is:

  • The default database handler, where sessions are stored in a database table along with the rest of you Drupal Application.
  • The Memcache handler, where sessions are stored in a Memcache server.
  • The Wincache handler, where sessions are stored in the Wincache Session Cache.

Introducing the different storage backends

The Database handler is developed and maintained inside Drupal Core. It uses the same database storage as the rest of your application, and is the one used by default when you setup a Drupal Application.

The Memcache handler uses the the Memcached memory object caching to store data. The session handler is maintained by the Memcache Drupal module team.

The Wincache handler uses the Wincache PHP extension to store data, and is maintained by the DrupalOnWindows.com team.

Of these three, Wincache is the one more different in nature. Both Database and Memcache build session handling over regular storage, while Wincache is fully integrated into the PHP pipeline. That means that for most use cases you just need to change you session handler in php.ini. But that's not the case for Drupal where the very custom session behaviour (such as not starting sessions for anonymous users unless data has been stored) needed a session wrapper provided by the Drupal Wincache Module. Wincache works in-memory through a PHP extension, while the other two consume network load to access their storage backends.

Another big difference is that Wincache is not able to adapt to storage requirements. If you configure your PHP.ini to have 85Mb of session storage for Wincache, then that will be the exact amount of memory that will be reserved from the start. On the other hand, the remaining storage backends will adapt their memory and storage requirements as usage grows.

Before we go any further and to make the comparison fair, we need to pinpoint the main differences between these storage systems.

Storage Persistent HTTPS Support Requires external software Can scale horizontally Max active sessions
Database Yes Yes No Yes Unlimited
Memcache No Yes Yes Yes Unlimited
Wincache Yes No No No ~51,000
  • Storage: The storage backend.
  • Persistent: Wether or not session session can recover from volatile storage downtime (system reboots, system failure, etc.) Users using Couchbase as their Memcache provider do indeed get persistent storage, but this is not the regular scenario.
  • HTTPS Support: If sessions are supported when your site is deployed in HTTPS.
  • Requires external software: If you need to install, maintain and configure a stand-alone piece of software different from the ones you are already using to run Drupal.
  • Can scale horizontally: If the storage backend allows you to scale you web application horizontally (not if the backend actually scales hortizontally itself). Wincache cannot be shared accross servers, but you can use session persistent load balacing algorithm to scale you application horizontally.
  • Max active sessions: The maximum amount of sessions that can be handled at the same time. Note that Database and Memcache backend give you virtually "unimited" storage, while Wincache is constrained to it's maximum storage size of 85Mb.

The setup

Usually your database engine or your memcache server will be installed and running on a different box than that of your web application (for maintenance, security and scalability reasons). Nevertheless we will be running our benchmarks with all software running on the same box.

This will make Wincache loose most of it's edge.

To run this test we used:

  • Cleanly installed new Drupal 7.34
  • MySQL 5.6.21 Community.
  • IIS 8.5 running on Windows 8.1 | Core i7-4712MQ | 16GB RAM DDR2 800 MHZ | SanDisk X210 SATA III
  • Couchbase 3.0.2 as the Memcached storage.

The only change made to a clean install was to setup the Wincache Lock and Cache backends in settings.php:

$conf['lock_inc'] = 'sites/all/modules/wincachedrupal/wincache-lock.inc';
$conf['cache_backends'][] = 'sites/all/modules/wincachedrupal/drupal_win_cache.inc';
$conf['cache_default_class'] = 'DrupalWinCache';

No other settings have been changed (no page cache, no css aggregation, etc..) everything is as default.

Just to get a reference of the base system performance, running an Apache Bench without concurrency (C=1) is giving us #73 requests per second, with an average 14ms per request.

To perform the test we prepared a custom script that we will be consuming from our benchmarking tools:

define('DRUPAL_ROOT', getcwd());
require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
global $user;
// Create some data.
$data = array();
for ($x = 0; $x < 100; $x++) {
  $user->data[] = md5($x);
// Store in session.
$user->data = array();
// Commit the session.
// Regenerate the session.
// Clear session, wincache has a special 
// drupal_session_destroy implementation.
if (function_exists('drupal_session_destroy')) {
else {
// Now create and store a session without destroy
// so that they accumulate throughout the test.
$user->data = array();
// Commit the session.

What are we going to measure

Finding performance indicators that are relevant for the three session handlers is not going to be easy. Some of the handlers are offloading work (CPU, Memory) to external systems such as a database enginge or a Memcache server, while others keep everything inside PHP. Some are persisting their sessions to disk, while others not.

So we are going to stick to the simplest indicator possible: measure throughput of the test script in Requests Per Second.

D:\xampp\apache\bin>ab -n 15000 -c 20 http://localhost:809/session_benchmark.php

NOTE: We had to disable Windows Defender to carry out the tests as network based handler's were inspected by the Network Realtime Analysis Service, leading to degraded performance. On Servers, of course, Windows Defender is not installed by default.

Results and conclusions

Storage C = 4 C = 8 C = 16 C = 32
Database 898 1447 1527 1661
Wincache 927 1623 1732 1809
Memcache 742 871 * 883

Table 1 - Test results in Requests Per Second. C is the concurrency parameter in Apache Bench.

Do not pay attention to the absolute values, but to the difference among handlers. We were not expecting Memcache to fall in the third place, actually that makes no sense at all because commonsense dictates that Memcache should be way faster than using Database as a storage handler, and scale much better.

Remember that both Memcache and Database server are on the same box as the web server, and that is not the regular neither recommeded setup. Expect the throughput differences to skyrocket (except for Wincache) when moving the storage to another box.

Although we did not record any specific indicators regarding CPU and Memory usage, we are noticed high CPU usage when running the test against the Database handler, this CPU being eaten by the database engine itself.

Our recommendation is to always use Wincache session handler if your session storage needs fit inside the max. 85Mb it is able to handle. Otherwise move to Memcache/Database backend storage. Here is a summary of pros/cons for these storage systems:

Storage Pros Cons
  • Works out of the box - this is Drupal's default handler
  • No need to setup or configure anything besides what you are already using
  • Additional network load
  • Additional pressure on database engine (can be significant, adding at least 3 I/O operations per request)
  • Depends on network performance (latency, load, etc.)
  • Needs very little setup
  • Extremely fast
  • No need for external software
  • No network usage
  • Low CPU usage when compared to other solutions
  • Size does not adapt on demand, it must be forecasted and set in your PHP.ini
  • Additional memory load on your webserver. If you run multiple websites on the same webserver, their memory needs will add up.
  • If you need to rescale the session cache size, you will have to reset all sessions.
  • You cannot share the storage between servers:needs a session persistent load balancing algorithm if you are scaling your application horizontally.
  • You need to modify all calls to session_destroy in core and contrib, replacing them with drupal_session_destroy.
  • Despite the results in the benchmarks, this should be faster than Database and scale better
  • Additional network load
  • Need to setup a Memcache server
  • Depends on network performance (latency, load, etc.)
  • Non persistent
  • Not available on Windows (unless you use Couchbase)

Add new comment

By: david_garcia Sunday, February 22, 2015 - 00:00