Download & Extend

Cache Stampede Effect in 1.9: If CACHE_TEMPORARY, expire time is left at -1 instead of being set to a time

Project:Memcache API and Integration
Version:5.x-1.9
Component:Code
Category:bug report
Priority:critical
Assigned:Unassigned
Status:closed (won't fix)

Issue Summary

You can generate near-100% miss rates on certain caches in 1.9 if the entity being cached uses CACHE_TEMPORARY. This means that there is a > 2:1 WRITE TO READ ratio.

Here's the problem:

Notice that in the code below, $expire is not (re-)set until after its value is assigned to $cache->expire.

This seems to result in the behavior that every CACHE_TEMPORARY item expires every time. (See dmemcache_get() for fetching code -- -1 is definitely less than time()).

Furthermore, $expire is never set to the actual expiration time. It is just the number of seconds to wait. The expire time should be variable_get('cache_lifetime', 2591999) + $time

<?php
function cache_set($cid, $table = 'cache', $data, $expire = CACHE_PERMANENT, $headers = NULL) {
 
$time = time();

 
// Create new cache object.
 
$cache = new stdClass;
 
$cache->cid = $cid;
 
$cache->data = is_object($data) ? memcache_clone($data) : $data;
 
$cache->created = $time;
 
$cache->expire = $expire;
 
$cache->headers = $headers;

 
// Save to memcache
 
if ($expire == CACHE_TEMPORARY) {
   
$expire = variable_get('cache_lifetime', 2591999);
  }
 
// We manually track the expire time in $cache->expire.  When the object
  // expires, we only allow one request to rebuild it to avoid cache stampedes.
  // Other requests for the expired object while it is still being rebuilt get
  // the expired object.
 
dmemcache_set($cid, $cache, 0, $table);
}
?>

I believe this bug should be marked critical, given the fact that it actually hurts overall system performance, rather than helping.

Comments

#1

Patch attached.

AttachmentSize
memcache-5x-19-20100114.patch 901 bytes

#2

Status:active» needs review

D'oh... sorry... should have marked this as "Needs Review"

#3

Will

#4

I have been looking at, what seems to be a similar issue (although mostly with cache clearing and D6):
http://drupal.org/node/572838#comment-2690370

#5

Status:needs review» closed (won't fix)

Just marked 5.x as unsupported, won't fixing this.