Install

Works with Drupal: 7.x

Using Composer to manage Drupal site dependencies

Downloads

Download memcache-7.x-1.6-rc1.tar.gztar.gz 53.49 KB
MD5: b831277498f096e25586f3023d777aa8
SHA-1: 40c4235e638614904ddb174e0d24b9d10ec1b708
SHA-256: 39ee84f8633087f02b97ae445bd90264c5d91f725df49983f922ac773b19dbbf
Download memcache-7.x-1.6-rc1.zipzip 62.56 KB
MD5: f4ca80dac83b847300fc6648f980130b
SHA-1: a6dd5556ba881eeebbb821437e149eeee68ece36
SHA-256: 90137dca0a0f27e9c0307b60c7c299e8d749b42ab7428049f95ed5a0dcf542d7

Release notes

It's Been Too Long Since We Had A Release

Help us test 7.x-1.6-rc1 to make sure there are no regressions compared to 7.x-1.5. Lots of bug fixes and useful new features were included in this release. The README is fully updated, documenting all new features that require configuration.

Always carefully test the update process and new release first in a development and/or staging environment before updating your production environment!

Highlights

  • Persistent connections are now enabled by default.
  • Introducing two memcache-specific drush commands; instantly flush an entire bin: drush mcf, review server statistics: drush mcs.
  • Improved debug output when memcache is misconfigured.
  • Properly handle over-sized cache items.
  • Support for the 'igbinary' and 'msgpack' extensions, optionally replacing php's serialize functions
  • PHP 7 support

What’s changed since 7.x-1.5

See the details below for everything that's changed since 7.x-1.5.

Overview

It's been two years since the last Drupal Memcache module release! Perhaps it's no coincidence that I also have a nearly two-year-old daughter. Excuses aside, there's a ton of important changes in this release, from optimizations and bug fixes to new features. What follows was extracted from the README.txt:

Drush
Enable the memcache module at admin/modules or with 'drush en memcache', then rebuild the drush cache by running 'drush cc drush'. This will enable the following drush commands:

  memcache-flush (mcf)  Flush all Memcached objects in a bin.
  memcache-stats (mcs)  Retrieve statistics from Memcached.

For more information about each command, use 'drush help'. For example:

  drush help mcf

Or:

  drush help mcs

Cache lifetime
Memcache respects Drupal core's minimum cache lifetime configuration. This setting affects all cached items, not just pages. In some cases, it may be desirable to cache different types of items for different amounts of time. You can override the minimum cache lifetime on a per-bin basis in settings.php. For example:

  // Cache pages for 60 seconds.
  $conf['cache_lifetime_cache_page'] = 60;
  // Cache menus for 10 minutes.
  $conf['cache_lifetime_menu'] = 600;

Cache header
Drupal core indicates whether or not a page was served out of the cache by setting the 'X-Drupal-Cache' response header with a value of HIT or MISS. If you'd like to confirm whether pages are actually being retreived from Memcache and not another backend, you can enable the following option:

  $conf['memcache_pagecache_header'] = TRUE;

When enabled, the Memcache module will add its own 'Drupal-Pagecache-Memcache' header. When cached pages are served out of the cache the header will include an 'age=' value indicating how many seconds ago the page was stored in the cache.

Persistent connections
As of 7.x-1.5, the memcache module uses peristent connections by default. If this causes you problems you can disable persistent connections by adding the following to your settings.php:

  $conf['memcache_persistent'] = FALSE;

Prefixing
If you want to have multiple Drupal installations share memcached instances, you need to include a unique prefix for each Drupal installation in the $conf array of settings.php. This can be a single string prefix, or a keyed array of bin => prefix pairs:

   $conf['memcache_key_prefix'] = 'something_unique';

Using a per-bin prefix:

   $conf['memcache_key_prefix'] = array(
     'default' => 'something_unique',
     'cache_page' => 'something_else_unique'
   );

In the above example, the 'something_unique' prefix will be used for all bins except for the 'cache_page' bin which will use the 'something_else_unique' prefix. Not that if using a keyed array for specifying prefix, you must specify the 'default' prefix.

It is also possible to specify multiple prefixes per bin. Only the first prefix will be used when setting/getting cache items, but all prefixes will be cleared when deleting cache items. This provides support for more complicated configurations such as a live instance and an administrative instance each with their own prefixes and therefore their own unique caches. Any time a cache item is deleted on either instance, it gets flushed on both -- thus, should an admin do something that flushes the page cache, it will appropriately get flushed on both instances. (For more discussion see the issue where support was added, https://www.drupal.org/node/1084448.) This feature is enabled when you configure prefixes as arrays within arrays. For example:

  // Live instance.
  $conf['memcache_key_prefix'] = array(
    'default' => array(
      'live_unique', // live cache prefix
      'admin_unique', // admin cache prefix
    ),
  );

The above would be the configuration of your live instance. Then, on your administrative instance you would flip the keys:

  // Administrative instance.
  $conf['memcache_key_prefix'] = array(
    'default' => array(
      'admin_unique', // admin cache prefix
      'live_unique', // live cache prefix
    ),
  );

Experimental - Alternative Serialize
This is a new experimental feature added to the memcache module in version 7.x-1.6 and should be tested carefully before utilizing in production.

To optimize how data is serialized before it is written to memcache, you can enable either the igbinary or msgpack PECL extension. Both switch from using PHP's own human-readable serialized data strucutres to more compact binary formats.

No specicial configuration is required. If both extensions are enabled, memcache will automatically use the igbinary extension. If only one extension is enabled, memcache will automatically use that extension.

You can optionally specify which extension is used by adding one of the following to your settings.php:

  // Force memcache to use PHP's core serialize functions
  $conf['memcache_serialize'] = 'serialize';

  // Force memcache to use the igbinary serialize functions (if available)
  $conf['memcache_serialize'] = 'igbinary';

  // Force memcache to use the msgpack serialize functions (if available)
  $conf['memcache_serialize'] = 'msgpack';

To review which serialize function is being used, enable the memcache_admin
module and visit admin/reports/memcache.

IGBINARY

The igbinary project is maintained on GitHub:
- https://github.com/phadej/igbinary

The official igbinary PECL extension can be found at:
- https://pecl.php.net/package/igbinary

Version 2.0.1 or greater is recommended.

MSGPACK

The msgpack project is maintained at:
- https://msgpack.org

The official msgpack PECL extension can be found at:
- https://pecl.php.net/package/msgpack

Version 2.0.2 or greater is recommended.

Debug logging
You can optionally enable debug logging by adding the following to your settings.php:

  $conf['memcache_debug_log'] = '/path/to/file.log';

By default, only the following memcache actions are logged: 'set', 'add', 'delete', and 'flush'. If you'd like to also log 'get' actions, enble verbose logging:

  $conf['memcache_debug_verbose'] = TRUE;

This file needs to be writable by the web server (and/or by drush) or you will see lots of watchdog errors. You are responsible for ensuring that the debug log doesn't get too large. By default, enabling debug logging will write logs looking something like:

  1484719570|add|semaphore|semaphore-memcache_system_list%3Acache_bootstrap|1
  1484719570|set|cache_bootstrap|cache_bootstrap-system_list|1
  1484719570|delete|semaphore|semaphore-memcache_system_list%3Acache_bootstrap|1

The default log format is pipe delineated, containing the following fields:

  timestamp|action|bin|cid|return code

You can specify a custom log format by setting the memcache_debug_log_format variable. Supported variables that will be replaced in your format are: '!timestamp', '!action', '!bin', '!cid', and '!rc'. For example, the default log format (note that it includes a new line at the
end) is:

  $conf['memcache_debug_log_format'] = "!timestamp|!action|!bin|!cid|!rc\n";

You can change the timestamp format by specifying a PHP date() format string in the memcache_debug_time_format variable. PHP date() formats are documented at http://php.net/manual/en/function.date.php. By default timestamps are written as a unix timestamp. For example:

  $conf['memcache_debug_time_format'] = 'U';

Amazon Elasticache
You can use the Drupal Memcache module to talk with Amazon Elasticache, but to enable Automatic Discovery you must use Amazon's forked version of the PECL Memcached extension with Dynamic Client Mode enabled.

Their PECL Memcached fork is maintained on GitHub:
- https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php

If you are using PHP 7 you need to select the php7 branch of their project.

Once the extension is installed, you can enable Dynamic Client Mode as follows:

  $conf['memcache_options'] = array(
    Memcached::OPT_DISTRIBUTION => Memcached::DISTRIBUTION_CONSISTENT,
    Memcached::OPT_CLIENT_MODE  => Memcached::DYNAMIC_CLIENT_MODE,
  );

You then configure the module normally. Amazon explains:

"If you use Automatic Discovery, you can use the cluster's configuration endpoint to configure your Memcached client."

If you don't want to use Automatic Discovery you don't need to install the forked PECL extension, Amazon explains:

"If you don't use Automatic Discovery, you must configure your client to use the individual node endpoints for reads and writes. You must also keep track of them as you add and remove nodes."

Details

Testing

The memcache module is a critical component of even the largest Drupal websites, so we take testing seriously. We have done comprehensive load testing of this release to ensure that there have been no performance regressions. Our load tests are freely available at https://github.com/tag1consulting/drupal-loadtest. There you will find scripts that assist in pre-populating a site with data and running a jMeter loadtest suite against the test website. While the tests aren’t comprehensive and only focus on common core functionality, they provide fantastic insight and detail into the performance differences between releases.

Created by: Jeremy
Created on: 23 Jan 2017 at 15:12 UTC
Last updated: 8 Feb 2017 at 19:03 UTC
Git tag 7.x-1.6-rc1
Bug fixes
New features

Other releases