Cloud Platform
Memcached in detail
Note: This article only covers Acquia’s non-Kubernetes version of Acquia Cloud infrastructure, referred to as Cloud Classic.
This article explains some of the more advanced features of Memcached. For an introduction to caching in general, see Caching Overview. For information on how to use Memcached with an Acquia Cloud-hosted Drupal website, see Using Memcached.
The use of Memcached and its memory management functions are often considered critically important to the functionality of many websites. After you have it configured on a basic level, you may find that your website needs some more specific tuning to get the greatest use out of it. To get this additional use, learn more about:
Memcached is a scalable, in-memory key-value store. As applications grow to accommodate more traffic (including data and requests), Memcached can be scaled by adding more servers (also called horizontal scaling) — something that is difficult to do with MySQL. The Memcached store can be distributed across multiple servers, all representing a single storage pool of cached data. Each server contains an associative array that represents a part of the pool. The Memcached client APIs use consistent hashing algorithms to determine which server to store and retrieve values for a particular key. The consistent hashing strategy allows for an even distribution of key-value pairs according to the memory allocated to each server in the pool, even when a server is added to or removed from the pool.
Each key-value pair is stored only in one location: there is no duplication across servers. This virtual architecture enables Memcached to be configured either to share memory with other processes across multiple servers, or consolidated to one or more dedicated Memcached servers. Memcached servers in a Memcached memory pool are unaware of each other. The servers track which data in their local array was least-recently used, and will purge that data as needed to make room for newer requests (called an eviction).
Different keys are randomly mapped to servers in a pool, which can explain why, sometimes, one Memcached server can display different statistics from another. This does not necessarily mean that something is wrong; it simply means that Drupal is sending different keys to each server, which is how consistent hashing operates.
Sometimes, one Memcached instance will display a disproportionate number of evictions, while the other servers in the pool will not. Having a few evictions is not necessarily bad - it effectively means Memcached is getting rid of old objects to make space for new ones. A website which is constantly churning one cache object (the cache of variables, for example) can put load on just one of its Memcached servers. The number of evictions can also be influenced by both the size and the volume (based on how the slabs in memory are being used) of objects being sent to that particular server.
If the amount of evictions seems to be causing issues, there are two main approaches to take:
Begin by analyzing what Drupal is sending to Memcached; it's not uncommon for excessive cache sets to be a symptom of a problem in Drupal that should be fixed.
Use New Relic's APM Pro tools to check the items Drupal is sending to the Database. Since Memcached is a cache for requests sent from Drupal to the Database layer, this is a good opportunity to analyze expensive database queries in detail. You can change which Drupal modules are saving to Memcached, by updating the settings.php file in your application code. We have a good example of excluding caching for the depcalc module in the Memcache Settings file in our Enabling Memcached documentation.
The execution of allocating additional memory is dependent upon the type of subscription:
Memcache works with a PHP extension (PECL memcache) that, in turn, interfaces with a background Memcached daemon.
The Memcached daemon divides the allocated memory into pages of a specified size. Each page contains chunks of a fixed size, each of which hold a key-value pair and some overhead memory. Any spare memory in a chunk cannot be used for anything else. If the chunk is too small, it won't be able to store the cached object. If it is too big, it will result in unused, wasted space.
To utilize memory more efficiently, Memcached allows different sized chunks, which are called slab classes. However, each page may hold only chunks of the same slab class. The largest slab class is 1MB. When Memcached stores a cached object, it looks for a page with the smallest slab class that will accommodate it.
Acquia customers should be aware of the following best practices when using Memcached:
settings.php, customers should not configure any Memcached attributes after the Acquia require line.
Memcached can be used in multisite Drupal applications, which contain separate databases (one for each website) that share a common codebase and hardware. Acquia uses the name of the database as a Memcached prefix to logically separate the data. Acquia Cloud adds the correct memcache_key_prefix value through Acquia-specific code in the website-specific settings.php files:
$conf['memcache_key_prefix'] = $conf['acquia_hosting_site_info']['db']['name'] . '_';Customers should not modify the memcache_key_prefix setting in settings.php — setting a memcache_key_prefix value manually can display unexpected behavior.
If your site experiences a growth in Memcached get/set times, for an application on Cloud Classic infrastructure, Acquia recommends dedicated Memcached servers. For each Drupal bootstrap, a connection to each Memcached server must be made. Websites with heavy traffic should run no more than three to four instances of Memcached, as the connection overhead will cost more than the scalability gained by more instances.
To determine whether moving to dedicated Memcached is the right decision, please file a support ticket.
Cloud Platform