[Plugin: Memcached Object Cache] does not work with multiple single site installations on same serve

I have already been working on a fix for this. Here is what the patch would look like:

Index: object-cache.php
===================================================================
--- object-cache.php	(revision 500316)
+++ object-cache.php	(working copy)
@@ -10,6 +10,11 @@
 Install this file to wp-content/object-cache.php
 */

+// Users with setups where multiple installs share a common wp-config.php can use this
+// to guarantee uniqueness for the keys generated by this object cache
+if ( !defined( 'WP_CACHE_KEY_SALT' ) )
+	define( 'WP_CACHE_KEY_SALT', 'wp' );
+
 function wp_cache_add($key, $data, $group = '', $expire = 0) {
 	global $wp_object_cache;

@@ -97,6 +102,7 @@

 	var $cache_enabled = true;
 	var $default_expiration = 0;
+	var $abspath = ''

 	function add($id, $data, $group = 'default', $expire = 0) {
 		$key = $this->key($id, $group);
@@ -263,7 +269,7 @@
 		else
 			$prefix = $this->blog_prefix;

-		return preg_replace('/\s+/', '', "$prefix$group:$key");
+		return preg_replace('/\s+/', '', WP_CACHE_KEY_SALT . ':' . $this->abspath . ":$prefix$group:$key");
 	}

 	function replace($id, $data, $group = 'default', $expire = 0) {
@@ -354,6 +360,8 @@
 	function WP_Object_Cache() {
 		global $memcached_servers;

+		$this->abspath = md5( ABSPATH );
+
 		if ( isset($memcached_servers) )
 			$buckets = $memcached_servers;
 		else

It would may require that you define WP_CACHE_KEY_SALT in wp-config.php, if you aren’t using separate actual installs at different installation paths.

Also, see:

https://www.ads-software.com/support/topic/plugin-memcached-object-cache-shared-memcached-servers-wrong-content-retuned?replies=3

I’d rather not invalidate existing keys (which could cause meltage) or add to the key length to support this edge configuration. How about WP_CACHE_KEY_SALT, default it to an empty string so that existing keys are not invalidated, and some phpdoc suggesting setting it to a random prefix and/or the hash of the abspath?

Ok, per the conversation that Ryan and I had, here is the new diff:

Index: object-cache.php
===================================================================
--- object-cache.php	(revision 500316)
+++ object-cache.php	(working copy)
@@ -10,6 +10,11 @@
 Install this file to wp-content/object-cache.php
 */

+// Users with setups where multiple installs share a common wp-config.php or $table_prefix
+// can use this to guarantee uniqueness for the keys generated by this object cache
+if ( !defined( 'WP_CACHE_KEY_SALT' ) )
+	define( 'WP_CACHE_KEY_SALT', '' );
+
 function wp_cache_add($key, $data, $group = '', $expire = 0) {
 	global $wp_object_cache;

@@ -263,7 +268,7 @@
 		else
 			$prefix = $this->blog_prefix;

-		return preg_replace('/\s+/', '', "$prefix$group:$key");
+		return preg_replace('/\s+/', '', WP_CACHE_KEY_SALT . "$prefix$group:$key");
 	}

 	function replace($id, $data, $group = 'default', $expire = 0) {

For those with such a configuration WP_CACHE_KEY_SALT should be configured in each sites wp-config.php if they share a wp-config.php or the same $table_prefix. Something such as md5(__FILE__), md5($_SERVER[‘HTTP_HOST’]) or md5(DB_NAME) could be used as potential values.

I just committed the changes for this to trunk in https://plugins.trac.www.ads-software.com/changeset/539529

I will follow up with a tag in the somewhat near future.

Thank you Ryan and Matt. I will give this a try.

I am getting a lot of leakage using plugin version 2.0.1 or 2.0.2. I tested both.

I use WordPress version 3.3.2. The server has several single site WordPress installations all with their own unique table_prefix.

To keep track of the most popular posts for each day I use a plugin I developed that counts a page view when template_redirect is triggered (not the most accurate but it helps avoid JavaScript to decrease load time when jQuery isn’t needed). The plugin stores the count for each page, and the top ten list, only in Memcached using unique keys and a unique group, so nothing is ever stored in the database. This is a pure Memcached plugin.

When the popular posts plugin runs using the drop-in Memcached plugin 2.0.1 or 2.0.2, the count is lost after a few minutes, or even a few hours. Other data is also lost like the WordPress Options that should be cached. They are lost, then added back to the cache, but I can see they were lost from Memcached then added again. I am able to see the data is lost when I view the Memcached slab that had and then lost the data. My most popular post plugin data isn’t added again until the next hourly cron job is run, unless I refresh it manually, and I then see all the counters for every page has lost the count so they are back to zero.

When I use the drop-in Memcached plugin 2.0 I have no problems ever with anything, not even my most popular posts plugin that exclusively uses Memcached. I only have problems with lost data when I use either 2.0.1 or 2.0.2.

The functions I use in my plugin are wp_cache_set (to replace or add the count or list), wp_cache_get, and wp_cache_delete (to refresh the list every 24 hours). The data stored for counts is a string, and for the list it is an array.

Over the course of several days my hit percentage with 2.0.1 or 2.0.2 is 76 to 85%. With 2.0 my hit percentage is 95 to 97%.

Do you have any ideas that could help me isolate the problem? Which version is being used by www.ads-software.com and WordPress.com, is it 2.0 or 2.0.1?

Sorry, How can i define WP_CACHE_KEY_SALT in wp-config.php?

Something like this?:

define('WP_CACHE_KEY_SALT', 'write_string_here');

Thank you very much for your excellent work in this plugin ??

@calvin13: You are correct. Just make sure to put that somewhere above:

/* That's all, stop editing! Happy blogging. */

On a CentOS 6.2 installation with both single site and multisite blogs installed on the same server with WordPress 3.4.1, and the Memcached plugin for each single site, and for each blog network, the efficiency for 2.0.1 is less than 84%. It is so bad I can’t even use the cache functions for WordPress or transient functions without losing the data, which means when WordPress stores objects in cache they have to replaced frequently accounting for the poor efficiency.

With 2.0 the efficiency was 95-97%, but that was before adding a multisite network.

@matt and @ryan are either of you seeing similar poor efficiency running this version of the plugin?

I’ve been running Memcached for years, but only started having efficiency issues with Memcached plugin version 2.0.1. I wish I had time to work on it myself.

I am very careful about which plugins I install, especially when they are free, because not everyone cares to write truly commercial quality plugins. This is one of the reasons I have come to trust the quality of the Memcached Object Cache drop-in plugin maintained by Ryan and Matt.

Over the past few months I have been plagued with issues that began with lost data. I have some plugins I wrote that only use Memcached so the database is never touched, and that data was disappearing, causing me to then rewrite the plugins to store the data in the database. Not at all okay, when a perfectly good cache exists.

This became one of those times when the most obvious answer was right in front of my face. About two months ago I had a problem where the Google Analytics for WordPress plugin loaded jQuery on single post pages when it wasn’t needed, thus slowing down the page. I wrote Yoast, the author, with the changes needed, but he never responded.

After reading some of Yoast’s recent statements for another of his plugins WordPress SEO, where he called another plugin author’s plugin broken, and other plugins and themes stupid for doing certain things I realized, if anyone was arrogant enough to think his plugin was the only plugin on a blog, and would thus execute a wp_cache_flush, or a wp_cache_delete function, it would be Yoast.

I went looking into WordPress SEO, and found the problem that had been plaguing me, and continuously deleting my cache, and negating the benefit of the cache on a constant basis. I commented out the wp_cache_flush and wp_cache_delete lines in Yoast’s WordPress SEO plugin, and my problems suddenly vanished. I am now using Memcached Object Cache 2.0.1 with zero problems, and my GET hit percentage is back up to 95 percent or better.

I just want to apologize to both Ryan and Matt for implying that Memcached Object Cache was the source of the problem, when it wasn’t. Thank you for a reliable plugin, and most of all for taking the time to provide such a solid plugin for free.

Just to confirm, does the newest version of the plugin work on multiple single-site installations on the same server and with the newest WordPress (3.4.1)?

Further offotpic: Todd, do you know of a good replacement for WordPress SEO by Yoast? My main beef so far is that he’s refused to give the option to disable it from the admin bar, but when you add on top of it a tendency of causing other plugins to malfunction, as you claim, I’d rather switch to a more sustainable SEO solution.

Yes. I run multiple single-site installations, and a mutli-site installation, on the same server all using this drop-in plugin without any issues.

Hey Todd,

all the negativity about me aside (you apparently do like my plugins). I’d like to know where you changed it exactly, so I can see what I can do about it.

BTW RE: the Analytics patch, I’ll have to look that one up, can’t remember seeing it, did you mean this one?