What is the best way (regarding performance) to set transients for logged in users?

Question

I have an option for my logged in users where they can hide the posts they dont want to see.

Everything works as expected until I implement transients. When I set the transients to cache the posts queries, the posts are not hidden until the transients expire.

So, what should I do? The only thing I can think of is to set a transient for each logged in user and reset it everytime a user hides a post.

I am asking this because I believe that if I have thousands of users, this solution might not be very effective regarding performance. Thus, what would you recommend me to do in this case?

Answer 1

The rule of thumb is not to do any caching, except for object caching, for logged in users. Actually IIRC object caching will give you exactly what you want.

But if you have to do it your way, you should make your cache keys to be based on the query and have different cache for different queries. A similar but maybe easier to grasp idea is do "group" users based on their settings and hold a cache for each group.

And btw transients are the wrong tool for caching, or to say it better, their use do not exempt you from doing cache invalidation as you usually don't want a situation were you sent a notification about new post but no one can read it because the cache is stale.

Answer 2

The Transients API is similar to the Options API and that means as of right now, unless they make a change in v4.1 or the future release, all of your transients are going to be moving in and out of the tableprefix_options table. If your website is busy, that means your going to have a ton of reading & writing taking place which defeats the purpose of caching in the first place.

As it stands, there are no hooks being made available that will alter the function and only three options are accepted:

1. Name of Transient
2. Value of Transient
3. Expiration of Transient

If you were to write your own code (ill-advised in this case), your option would be to hack core, which is going against best practices and you'd be on your own for support as any issues arising from such would result in the community (mods and other users) advising you to revert back and see if the issue persists.

That being said, my advice would be to make use of the options outside of WordPress and combine them with what is available to WordPress by way of a plugin. This means enabling Query Caching through MySQL/MariaDB/Percona/etc, using Memcached or Redis etc (Redis wins over Memcached unless you're storing extremely small bits and pieces). This way you have a data store that isn't going to hammer one specific table over and over again.

W3 Total Cache supports APC & Memcached for Object & Database Caching (as well as File Caching, but it's often not recommended, especially if you have super-slow disks - i.e. anything other than SSD's), but it's bulky and likely overkill as the vast majority of the options can be done at the server level (i.e. file caching, browser caching etc). For Redis, you can use WP Redis and it'll handle object caching for you and it's to the point. If you've never used Redis, I'd check out:

redis.io (can't post another link else I'd of linked it for you :))

---

To enable Query Caching within MySQL, you should simply need to make sure the following exists in your my.cnf (normally /etc/my.cnf or /etc/mysql/my.cnf depending on OS):

query_cache_size = TOTALCACHESIZE
query_cache_type = 1
query_cache_limit = LIMITSIZEOFRESULT

Where TOTALCACHESIZE is the total size of the query cache as a whole and LIMITSIZEOFRESULT is the maximum result size that will be cached. Anything over this size will be ignored. You can specify the sizes in K OR M (no B on the end) like so (this would be a general starting point):

query_cache_limit = 512K
query_cache_size = 16M
query_cache_type = 1

NOTE: BEFORE dropping that in, shut down MySQL, backup your my.cnf file and then make the changes.

If you make changes while MySQL is running and then restart/reload in to the new config, it is possible you're get an error stating that MySQL failed to properly shut down and you'll then have to troubleshoot (it's happened to me a few times).

Beyond that, there are other ways to speed up MySQL by modifying the configuration, but it's too easy to get carried away, so starting with one of the easiest methods to speed things up while increasing performance is the best route.