Bug #5836
closedMemcached caching strategy on new server
0%
Description
This isn't really an issue, but thought we needed a space to document this and I didn't want to use the CAC group or an email chain to state this.
On the new server, we have chosen to use Memcached and the WP PECL Memcached Object Cache plugin:
https://github.com/tollmanz/wordpress-pecl-memcached-object-cache
If Memcached is used for other sites (not just the Commons), there is the potential for cache collisions to occur due to the cache key being the same by default.
To fix this, we should define the 'WP_CACHE_KEY_SALT' constant in wp-config.php for each site that is going to use Memcached:
https://github.com/tollmanz/wordpress-pecl-memcached-object-cache/blob/master/object-cache.php#L836
On the dev site for NYCDH.org, I'm using this:
// Memcached object cache unique key define( 'WP_CACHE_KEY_SALT', DB_NAME . ':dev:' );
Boone, we should probably commit a variation of this for CAC 1.9.22 before the migration takes place. Let me know if you'd prefer a different prefix.
Updated by Boone Gorges over 8 years ago
Thanks, Ray. The same thing had occurred to me, but I didn't open a ticket for it.
Using the DB_NAME as a cache key salt sounds like a good and easy strategy for us. On our current setup, it's not possible that two sites with the same DB_NAME will be sharing the same Memcached space. I don't know that an infix like ':dev:' is necessary for this purpose, but I'm happy to be convinced otherwise.
You want to go ahead and make the change? This is probably something that can go in our version-controlled wp-config.php file.
Updated by Raymond Hoh over 8 years ago
I don't know that an infix like ':dev:' is necessary for this purpose, but I'm happy to be convinced otherwise.
My reason for adding this is if we decide to enable Memcached on the dev server (/DEV_WWW/html/commons/www/) as well.
Are we going to try and emulate the production environment on the dev server? If we're not going to enable Memcached there, then we do not need to add the :dev: / :prod: suffix.
Updated by Boone Gorges over 8 years ago
- Assignee changed from Boone Gorges to Raymond Hoh
My reason for adding this is if we decide to enable Memcached on the dev server (/DEV_WWW/html/commons/www/) as well.
Gotcha. This makes sense. Yes, we are going to use Memcached on LDV1, but it'll be using memory space on LDV1 - there will be no interaction with the production Memcached server.
However, you're right that it'd be best practice, moving forward, to use a salt that includes something about the environment type. We already have an ENV_TYPE constant that I use to display the little red flag on non-production sites. What do you think about using a sanitized version of that? That way it'll be one less thing to remember to change if switching between environments.
Updated by Raymond Hoh over 8 years ago
What do you think about using a sanitized version of that? That way it'll be one less thing to remember to change if switching between environments.
Done. Let me know what you think of commit 4572759.