Optimize FastChainedCacheBackend by introducing heat based shut off

This looks like a good change to me, couple of comments:

1. I think we can just count writes/invalidations per-request rather than per-second. Module install and configuration sync are the most likely offenders and those generally happen within a single request. Also means nothing persistent to store.

2. We should try to avoid an extra consistent cache hit to get the shut off value - could possibly re-use the query for last write timestamp.

I've put together a very naive implementation. Just writes directly to the consistent cache if the threshold is reached.

+++ b/core/lib/Drupal/Core/Cache/TemperatureAwareChainedFastBackend.php
@@ -0,0 +1,77 @@
+/**
+ * A chained fast backend which shuts down fast cache if there are too many
+ * writes per request.
+ */
+class TemperatureAwareChainedFastBackend extends ChainedFastBackend {

We should certainly explain the idea implemented in that class

Do we really need this as a separate implementation? Shouldn't we just make it part of the existing class?

This isn't something that you want to explicitly enable IMHO, it should just work...

Thanks for the feedback.

Moves the threshold logic into ChainedFastBackend and inlines condition.

Spoke with @Fabianx at Drupalcon sprint, and agreed to write out how many writes we are doing per request during install to see what a good threshold is.

Re-read the issue summary, and found we aren't using this in the installer as per #2422657: Skip fast chained cache backend during installer.

After installing, I couldn't find any good examples where we were writing to the cache more than 20 times per request, which seemed insignificant.

Did you try [Flush all caches] or manually clearing the cache tables?

One big problem is also cache tag invalidations. For example, try something like my field_map.php script in #2473983: [meta] Evaluate Entity Field API Scalability, there's a huge number of cache tag invalidations going on, and every time one happens, the fast chained invalidates, and that happens for any bin that's using it. Any ideas on how to improve that?

I don't think this patch helps much at the moment.

Writing to the fast backend is fast. We don't need to worry about that.

The expensive part is markAsOutdated(), specifically in combination with cache tag invalidations as written above. Because every invalidation in turn calls that. Keep in mind that we do that for each fast chained bin. So by default, for every cache tag invalidation, we call markAsOutdated() on 3 different bins. And if you add more (I made default also fast chained on some of my sites as there is pretty much nothing left in there), that number increases.

So one thing we could try is something similar to DatabaseCacheTagsChecksum and avoid calling it repeatedly, unless we are fetching caches again. Will only work well if we don't fetch caches inbetween, need to do some tests on that.

Something like this.

To test, e.g. put something like this in a test:

debug(ChainedFastBackend::$invalidatedCounter, 'current');
    $this->rebuildAll();
    debug(ChainedFastBackend::$invalidatedCounter, 'after rebuild');

In my case in FolderTest, an absolutely trivial test, the numbers went from ~320/380 to 70/79, this is already a nice improvement. I'd expect the number goes up the more modules are enabled, so we should also try something like that in a normal standard install.

Also, make sure you run the test in the browser UI ;)

Might want to open a separate issue, since this doesn't have anything in common really with this issue, but as written above, I'm not sure this issue can help much in general. We avoid the likely cheapest part of the whole thing only.

I've been working on something for the ChainedFastBackend and came accross this issue.

The whole point of binary invalidation is to be able to have consistent and reliable cache values between environments (or "webheads"). If we only had one environment, we would actually not need this at all.

So why should we invalidate our own environment instead of only the other ones - if any. See patch attached - quite simple indeed- where we keep track of what "environment" has done the last binary invalidation and use this information not to invalidate the binary for the environment that has made the invalidation itself.

Indeed, I believe that with this change what happened in:

#2422657: Skip fast chained cache backend during installer

Would not have been needed at all as the install process happens on just on environment.

This is just a POF, maybe I got something wrong...

Another interesting change would be to move the actual binary invalidations to the end of the request, and do them all at once.

I'm setting this to needs review because I'm curious on seeing if this patch passes tests.

Ups...

Moving it away to it's own place #2611400: [meta] ChainedFastBackend should not invalidate the whole fastBackend when doing a Set()

Even if that ever ends up working, the aim of this issue is still completely valid.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

This is probably a duplicate of #3526080: Reduce write contention to the fast and consistent backend in ChainedFastBackend at this point - the other issue is much newer and the approach is different, but it's trying to solve the same problem.

Works for me!