0

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?

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.

  • Could you please provide more info about IIRC object caching? I plan to have thousands of logged in users. By the way, I am using transients for caching wp_querys only. And I do delete transients when needed. I also have memcache running on my server. – Gixty Dec 9 '14 at 6:10
  • 1
    hmmm, I am actually shocked to see that there is no real article that explains it, guess that in this case the code is the real documentation. tollmanz.com/grokking-the-wp-object-cache is a good explanation of the basics of object caching, but you will need to find plugins to connect it to memory based storage like APC or memcache. using APC for php caching is a no brainer for any site which expects to see some load so an APC based object caching requires very little extra work. – Mark Kaplun Dec 9 '14 at 6:52
1

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.

  • Adding to the above, Transients, unless managed and manually expired are not guaranteed to expire when you tell them to. When you provide an expiration time, you're simply telling WordPress that's when you'd like for it to expire. It may expire on the dot, but in most cases, the transient will remain a while longer. Transients are not meant to replace object, database and/or file caching. They're simply a tool to cache results that benefit from immediate and time-specific caching. If you're going to add and remove, the other 3 are the way to go. – Jonathan Dec 9 '14 at 7:08
  • Hello Jonathan, I will go over your answers as soon as I got the time. Is there a way I can contact you off site? – Gixty Dec 10 '14 at 3:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.