Problem/Motivation
The FastChainedCacheBackend is very useful provided that the data is mostly read, but not written often, as any write or clear leads to a full invalidation of the whole cache bin.
#2422657: Skip fast chained cache backend during installer →
improved the installer performance by removing the FastChainedCacheBackend during the installer, such especially saving the calls to markAsOutdated().
📌
Optimize config entity import
Closed: outdated
sees the same problem with config entity import.
However it is possible that completely valid writes would lead to the same problem.
The FastChainedCache backend is at one point very ineffective and just leading to more database writes, than what it saves.
Proposed resolution: Shut off for a period of time
It makes sense hence to shut off the chained backend for periods of time and just use the consistent cache backend instead directly.
Shutting off is fortunately very easy:
Just writing a 'future timestamp' (e.g. 10 s into the future) and ensuring that a cache is never read / written or marked as outdated, when the current_ts < future_ts.
This is the first task to implement and should be fairly easy.
However what now remains is:
When should the fast backend be shut down?
In computer science a problem space like this is usually modeled via: "Oracle" (not the company) and the number of writes / time when the performance suffers is called the 'break-even' time.
Oracle knows all requests in advance and such can lead to an optimal policy, where the fast chained backend is shut off
Fortunately looking at the problem space like this, it can be compared with a device that 'overheats' when it gets too hot, where hot here is defined as the number of writes per time. This means the problem can be simulated well.
e.g. a very simple policy would be. If there is more than 20 writes within the interval of a second, then shut off for 10 seconds.
In our simple model this would mean:
- cool down temperature == 20 writes / second
- a threshold of e.g. 20 writes when we shut off
- a shut down time of e.g. 10s
whenever we write markAsOutdated() and are not in shutdown we:
- decrement the temperate by the cooldown * duration the backend was inactive
- increment the temperature per markAsOutdated request
Remaining tasks
- Discuss
- Prototype (simple)
- Implement a TemperatureAwareFastChainedCacheBackend extends FastChainedCacheBackend
- Implement shut off function in the that can be called with a time to shut off for.
- Ensure shut off is taken into account by read / write / markAsOutdated()
- Implement a generic 'SimpleCacheTemperature' component (as this could be useful for other caches as well)
- Implement a generic 'CacheTemperatureInterface' with the function calculateTemperature(duration, number_of_writes)
- Add as service cache.temperature.simple
- Inject service into the TemperatureAwareFastChainedCacheBackend
* Benchmark
User interface changes
- None
API changes
- None