Maximum lifetime of cache objects. Why 180 sec?

There’s no one size fits all recommendation here, we ship W3 Total Cache with sensible settings that will provide a measurable benefit to the greatest number of people. You can experiment with different settings an observe the results, the optimal configuration depends on a range of factors specific to your site / theme / queries being run.

Thanks for your reply. However I can’t do much with it…

Can you tell me more about the pro’s and con’s of a max lifetime of 180 seconds? In what cases should someone use 180 seconds?

Can it be a good idea to change the setting to 1 day? What are the pro’s and cons?

Cheers ??

Posts and user records (and many others) can be stored in the database cache, so if you were to set a very long cache lifetime (like 24 hours), it could cause quite a few problems.

For example, if you edit an existing post, the cached copy could still be served until it expires, or if you change a user password, the old password might still be in the cache, and the new password wouldn’t work (for up to 24 hours in the example above). Your category and post pages might also not show new posts for up to 24 hours.

At the same time, for the above situations, 180 seconds might not be too bad. It could confusing for password changes, but you probably wouldn’t change your password, log off, and log back on in that short amount of time very often. (If you’re the only user, that’s probably not too bad.)

For one plugin I have seen that manages free user registration, the database cache wouldn’t work at all, even at 180 seconds — when someone would register, the plugin ran a query to make sure the user didn’t exist yet, next it created the user, then it redirected the user to a different page (so they could see it as a logged-in user) and it ran the first query again to pull the user’s information — but the cached result of the first query made it think that the user didn’t exist!

I think you can exclude the users and usermeta tables from database caching, which might have helped with that plugin, but we found the browser and page caching to be enough for our purposes, and didn’t want to risk similar issues with other parts of WordPress or plugins.

Many, many thanks mwrusnak! This is the explanation I was looking for. Very clear. So strange that this info couldn’t be found on the web or on the w3 website…

I run a website that is developed on a local machine. Once a new release is ready, we “copy” it to our live server. No posts are added or edited on our live server. So it would make sense, for my case, to change the max lifetime to e.g. 1 day (since no users login to my live site)? Right?

Cheers ??

It sounds like it could work, but I haven’t heard of anyone trying such a long lifetime yet, so there still could be problems that no one has considered yet, especially if you are using any other plugins on the site.

Personally — if it was a client or employer’s site, I wouldn’t try it at all. If it was my personal site and I didn’t mind breaking it temporarily (should something go wrong), I might try it — but I wouldn’t expect a huge performance boost, especially if using the “page cache” already.

If you overwrite the existing files when copying the dev site to the live server, you might also need to flush the database cache on the live server afterward, to make sure no old data is still cached.

Good luck if you do try it!

Thanks for the info. I’ll give it a shot.

Now I (somewhat) understand it, trial and error / testing will be more effective ??