Flush per site cache #33
Conversation
|
Thanks for the PR! How long have you been using this in production already? |
|
We haven't used this in production, because if we update the plugin the feature will be lost, and that's the reason I create this pull request. However, the code has passed our code review :) |
|
I'd be open to merging this after you tested this feature thoroughly. Any chance you guys could manually apply the changes and see how it goes? |
|
OK, we will test it on our dev environment for days, and if it works fine, we will deploy it on MSDN blog production. I will inform you when we decide to deploy it on production, and you may consider when to merge it then :) |
|
The plugin has been tested on PPE (test env) for a half month, and we have deployed it on our production today. I move "Flush Cache" link from custom column to row action as shown in our production below:
|
|
Nice, keep me posted. |
|
This is terrific, I'm super interested. |
|
@Sneezry: Can you fix the conflicts? |
|
OK, I'll fix it in few days. |
|
This would be nice to have as well: https://make.wordpress.org/core/2016/10/04/custom-bulk-actions/ |
|
We just implemented selective cache key flushing that uses the It seems like a cache-invalidation nightmare to me because of the global groups, like the |
|
Woooow! That is great! My code has to cache all key name in an index, and
that makes redis write twice. Code in #53 is awesome!
Till Krüss <notifications@github.com>于2016年11月28日 周一上午7:09写道：
… We just implemented selective cache key flushing that uses the
WP_CACHE_KEY_SALT constant in #53
<#53> and I have to say I'm
not sure if a per-site cache flush makes sense to me.
It seems like a cache-invalidation nightmare to me because of the global
groups, like the users table. If someone can describe a scenario in which
they would greatly benefit from a per-site flush and they have a solid
solution for this let me know. Otherwise prefer not to merge this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#33 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABi9Ldt7PGi-ZoT7Bujf_VSsri2WJ83yks5rCg2cgaJpZM4JQdSG>
.
|
|
So are you saying you're thinking of moving away from this PR in favour of a cache salt approach (#53)? In a multisite scenario then would one have to all the site-id to the cache salt to have functionality similar to this? Being able to clear a cache for a single site in a high traffic multisite environment is a definite use case that we have as flushing the db causes a large performance drop. Typically in this environment visitors do not login with WordPress therefore not flushing the users table is ok. However I can also see implementations where this could be a problem, so perhaps this PR simple needs a setting/option for flushing the 'shared cache' along with a site flush so that we can have that control. |
|
@svandragt: No, I'd still like to see better multisite support in the plugin, but it has to be implemented in a way that works great out-of-the-box for "regular" users and we can "unlock" different scenarios with A few thoughts: By default the entire cache should be flushed, multisite or not. Next level could be a constant that enables per-site flushing (under "Sites"), which would also flush all shared/global groups. However it must still be possible to flush the entire cache somewhere. Maybe Network -> Settings -> Redis? There should be WP CLI commands for flushing...:
If another separate constant is added that prevents the global groups from being flushed in multisite environments, then there should be a button to flush global groups somewhere. Maybe as well under Network -> Settings -> Redis? |
We are using a multisite setup (~4000 websites and counting) where we each site has an internal url of the form slug.ourcompany.com until the site moves to production, at which point our provisioner application edits all urls in the database for that site to change them to the real url. This implies a cache flush. Obviously, with that many sites, a cache flush is be pretty damaging to performance. As it stands we are holding of our impending doom by cunningly queueing connections in nginx so the database never gets overwhelmed, but ideally we would like a per site flush to be possible. One option I am toying with is to set the WP_CACHE_KEY_SALT to md5($_SERVER['SERVER_NAME']) and using WP_REDIS_SELECTIVE_FLUSH, but I am not yet sure of the implications. For one thing it may make it difficult to use wp-cli. |
|
@ravloony: That should work fine, better than flushing all sites at once. Depends how many hits you have per second on those 4000 sites. I never use hashes as prefixes, because it makes impossible to find manually, instead I usually use a sanitized string of the domain, like |
|
To be honest, I don't like the approach of this PR, using The "Flush Cache" UI link is great, tho. We should just use the selective flush constant and allow cache flushing via network admin and normal admin UI. If anyone wants to make a PR, that'd be great! |
Redis Object Cache provides a Flush Cache button, however, it clears the entire DB. We have a multisite WordPress with thousands of blogs, and to flush all cache may lead performance problem to us. So I make some changes to flush per site cache. This feature is only available for network sites. A Flush Cache link will be added in each site line in Network Sites menu.