Object Caching still not compatible?

#1

I know the old recommendation from Jason says to disable any object caching, but I’m wondering if that’s still the case.

Is anyone using Redis or Memcached to cache db queries? I use that for all my non-s2 sites and would like to use the same server stack for all of the sites since I’m upgrading them all right now.

I’m wondering if object caching back then meant something different than caching db queries in memory now or if it’s that s2 still doesn’t purge entries.

@clavaque Any thoughts or future plans here?

S2member-pro breaking website with PHP 8
#2

s2Member stores details about users in the options table of the database. While it continues to do that, it’s not going to be possible to use object caching reliably. This is actually the reason that, after many years, I finally stopped using s2Member and wrote my own custom code for my use cases.

S2member-pro breaking website with PHP 8
#3

Thanks for jumping in. I remember you from these forums in the past.

Oh well. I can migrate too, but it’s not worth it for the sites I have that still use s2, which are in topics that aren’t so popular anymore. Anything new gets something else anyway.

I don’t need object caching on them, but it would be nice to have, especially for my own selfish reasons just to speed up the admin a bit.

S2Member and LiteSpeed Question
#4

I found a comment Jason wrote a few years ago about Object Caching in a chat, and thought it’d be good to quote it here:

WordPress comes with its own Object Cache built-in (see WP Object Cache), as do many plugins for WordPress (including bbPress). The drop-in plugin file /wp-content/object-cache.php allows for a so-called Advanced Object Cache to take things a step further; e.g., caching transients into memory, and doing a persistent cache of what WordPress already deals with. We have not seen a single reliable implementation of an Advanced Objet Cache. Object caching that comes with WordPress already + Page caching with a plugin like Comet Cache is generally more than enough and the only scenario where it makes sense to add another layer of Advanced Object Caching is on completely custom, very high traffic WordPress sites where every single plugin and even the theme itself has been reviewed and tweaked to take advantage of the Advanced Object Cache (e.g., the NY Times blogs, which have a team of WordPress developers who tweak WordPress for high-availability).

Object caching is very specific to the PHP code itself (i.e., where the objects are created; the PHP code needs to take into consideration that the objects it creates might get cached). Many WordPress plugins are not written with object caching in mind, which is why adding Advanced Object Caching to a WordPress site with many different WordPress plugins often causes strange and seemingly mysterious issues. Larger and more well-maintained plugins like bbPress and BuddyPress are already written to take advantage of object caching, so adding another Advanced Object Cache will generally not produce any improvement in speed when it comes to those plugins.

:slight_smile:

S2member-pro breaking website with PHP 8
#5

there is a difference between direct object caching PHP/nginx or object cachging enabling via plugin (also using memchaed or redis). Via plugins works usually well - via PHP directly as with memcached or redisI could not get it to work with many plugins.

#6

Agreed. This doesn’t sound like what I’m referring to: Caching database queries to Redis or Memcached to speed up large queries that don’t change often or the same query run on the same page multiple times. From my basic understanding, WP has a built-in way to expire the cached objects when they change, which allows support for dynamic content like membership sites. I haven’t dug into it, but I assume it’s just a matter of making sure plugins put in the actions to expire the cache for the specific query whenever something that would affect the operation of the plugin changes in the db. So then WP clears that cached object from Redis/Memcached (or, more specifically, probably allows the caching plugins to react via a hook), and the next time it needs to run the query it doesn’t find it in cache, so it goes to MySQL to grab it and caches the response. Of course, it’s probably way more complicated than this, but this is how I think of it without having actually tried to implement or research how to implement it as a plugin developer (which I’m not).

1 Like