I've thoroughly analyzed WP's cache, its functions and what it does and although simple in its design, it's effective: an object where you keep adding data that might be used somewhere else, so you don't hit the database.
Alright, but PHP is stateless. It remembers nothing between its sessions when talking about dynamic entities, so, every new request means a new lifecycle.
It's clearly not in the database. It also probably doesn't make sense to have a "globally shared" cache, because each user's variables might be different, so, if an user requests posts in a certain manner, another one most likely will request it in another manner (filters) and clearly, WordPress doesn't do it - it's not in the database either as a transient / option.
How does it happen, then?
Given that it's stateless, isn't the cache useless unless the same query was run twice? Because it dies on session close, a query ran before won't be there for you to retrieve its results for.
Edit:
I understand what __destruct does, but in this case, the cache isn't saved nor in a session variable, nor in the user's cache, nor...nowhere, it just returns True.
I've thoroughly analyzed WP's cache, its functions and what it does and although simple in its design, it's effective: an object where you keep adding data that might be used somewhere else, so you don't hit the database.
Alright, but PHP is stateless. It remembers nothing between its sessions when talking about dynamic entities, so, every new request means a new lifecycle.
It's clearly not in the database. It also probably doesn't make sense to have a "globally shared" cache, because each user's variables might be different, so, if an user requests posts in a certain manner, another one most likely will request it in another manner (filters) and clearly, WordPress doesn't do it - it's not in the database either as a transient / option.
How does it happen, then?
Given that it's stateless, isn't the cache useless unless the same query was run twice? Because it dies on session close, a query ran before won't be there for you to retrieve its results for.
Edit:
I understand what __destruct does, but in this case, the cache isn't saved nor in a session variable, nor in the user's cache, nor...nowhere, it just returns True.
- 1 the simple answer is that the object cache doesn't maintain persistence between page loads. there are more times than you might think where the same DB query would be run multiple times on a page load (options are a good example). it's all just obfuscated behind core functions – mrben522 Commented Mar 6, 2019 at 15:29
- check out this answer for more details – mrben522 Commented Mar 6, 2019 at 15:29
- @mrben522 That would make sense then. I assume that's exactly (among other reasons) why memcached was created, so that you could cache these objects between lifecycles? – coolpasta Commented Mar 6, 2019 at 15:32
1 Answer
Reset to default 2The short answer is: it doesn't
That doesn't mean it can't be made persistent, and it doesn't mean it doesn't improve performance.
Performance Gains Despite No Persistence
Lets say we fetch 5 posts, and on each post we retrieve various post meta. You might think that each call to get_post_meta results in an additional DB query, but you would be wrong. WP fetches all the post meta in advance, and stores it via WP Cache. When the template fetches those values, it's grabbed from WP Cache avoiding multiple database queries.
Likewise, if you use various functions to retrieve terms, posts, etc, they're cached in WP Cache. This way, WP Cache can be used to make sure that data is only fetched once from the database, and acts as an optimisation, even if WP Cache is lost at the end of the request. You'll see a lot of intermediate developers attempt to implement this to avoid DB queries, unawares that WP already does this behind the scenes
Making it Persistent
You can use a drop-in file to provide a WP Cache implementation that uses a persistent data store. I for example use a Memcached dropin, of which there are several implementations. This is usually done using a keystore no-SQL database that stores the data in memory.
As for per user data, this isn't persisted, or if it is, it's namespaced or has the user ID in the key so that it doesn't clash.
Keep in mind this will require 3rd party software, be it Memcache, Redis, etc Most hosts won't provide this.
Having said that, the performance gains of a persistent object cache can be immense
Transients
Transients are the only part that do persist, they're stored in the options table. However, if a persistent object cache is present, they're also cached in WP Cache giving a speed boost.
Full Page Caching
WP doesn't do page caching, but this can be added via plugins. How these plugins do this however depends on the plugin, with many different methods and implementations, you will need to refer to the plugins documentation and support avenues