search

tollmanz / wordpress-pecl-memcached-object-cache

A WordPress object cache that uses the memcached (not memcache) PECL extension.
233 stars 114 forks source link

Can I use this alongside a full-page cache like WP-Supercache or WP-FFPC? #67

Closed jeffwidman closed 9 years ago

jeffwidman commented 9 years ago

This isn't so much of a bug report as a question about how object-caching in Wordpress actually works under the covers. I thought I understood Wordpress caching, but then I read some docs + code, and now I'm confused... any help is appreciated.

I'm trying to accomplish the following:

  1. Use Wordpress built-in caching mechanism to cache stuff for logged-in users. From my understanding, this stores the output of object compilation so PHP can work with pre-assembled objects and doesn't have to recompute values and re-hit the DB... among other things, it can make the admin panels faster. I've been happily using this plugin to tell Wordpress to use memcache as the backend for the built-in object cache with no issues.
  2. Add a full-page cache for logged-out users. I'd like to use WP-FFPC or WP-Supercache to serve pre-generated pages from Nginx/memcache or Nginx/disk and entirely skip the PHP interpreter/MySQL.

Conceptually these are very different, so I assumed they wouldn't conflict, but I just tried installing WP-FFPC and WP-Supercache, and both of them require that I set define('WP_CACHE', true); in wp-config.php, which makes me wonder if my mental model of Wordpress caching is inaccurate? Any idea if those full-page caching plugins will conflict with this object-cache?

Cross-posting here: https://github.com/petermolnar/wp-ffpc/issues/40

tollmanz commented 9 years ago

Use Wordpress built-in caching mechanism to cache stuff for logged-in users. From my understanding, this stores the output of object compilation so PHP can work with pre-assembled objects and doesn't have to recompute values and re-hit the DB... among other things, it can make the admin panels faster. I've been happily using this plugin to tell Wordpress to use memcache as the backend for the built-in object cache with no issues.

This first concern is roughly describing WordPress' object caching behavior. To implement object caching in WordPress, you need to install a 3rd party object cache that persists data to some storage engine. That is exactly what this library does. By dropping in this library, you are able to persistently cache data to memcached. This means that data that is generated and stored during one request will be available for subsequent requests without the high overhead of generating that data again. I've written an deep dive on object caching in WordPress if you'd like more details.

You should know that by just installing an object cache, you get all sorts of performance benefits. WordPress core code uses the object cache internally so you get instant benefit because those uses of the object cache begin to store and retrieve persistent data.

Add a full-page cache for logged-out users. I'd like to use WP-FFPC or WP-Supercache to serve pre-generated pages from Nginx/memcache or Nginx/disk and entirely skip the PHP interpreter/MySQL.

You definitely want a full page cache. Typically, a well developed WordPress page cache will only cache pages for non-logged in users. Logged in users generate the page each time so that the data is specific to them. I've written about this as well. For my money, you can't go wrong with Batcache as a page cache for many sites.

Conceptually these are very different, so I assumed they wouldn't conflict, but I just tried installing WP-FFPC and WP-Supercache, and both of them require that I set define('WP_CACHE', true); in wp-config.php, which makes me wonder if my mental model of Wordpress caching is inaccurate? Any idea if those full-page caching plugins will conflict with this object-cache?

No. These things do not conflict; rather, they are complimentary. For instance, if you want to use this library for object caching and batcache for page caching, batcache will use memcached as the storage engine. This is set up this way intentionally. You chose an object cache which simply defined how the cached data is stored. The page cache builds on top of this by defining logic for generating the page cache, but doesn't care how it is stored. That is the job of the object cache.

define('WP_CACHE', true);

Unfortunately, people often abuse the meaning of the WP_CACHE constant (probably because its named poorly). In the most technical terms, WP_CACHE simply means "load the file located at /path/to/wordpress/wp-content/advanced-cache.php". Technically, you can do anything with the code in that file; however, it is specifically meant for defining the page cache. So, WP_CACHE means "load the page cache".

People often confuse WP_CACHE with having implications for the object cache, but it does not. It has no bearing on how the object cache is handled. It's quite inconsistent as there is no constant to toggle the object cache on and off. Instead, the object cache is turned on if a file is located at /path/to/wordpress/wp-content/object-cache.php. If that file is available, WordPress loads it and does not load the internal object cache.

So...my recommendation if you are looking to have a single server, high performance WordPress site is to install this object cache and batcache. It essentially what WordPress.com does and they handle some 50 million websites with over a billion monthly page views. The software is proven and uses the caching features of WordPress correctly.

joelataylor commented 9 years ago

I know this is closed, but wanted to thank you @tollmanz for the awesome (clear) description above!