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.
The 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.
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
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 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.
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
