[wp-trac] [WordPress Trac] #32184: Extended cache control

[WordPress Trac]

#32184: Extended cache control
-------------------------+-----------------------------
 Reporter:  jipmoors     |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Cache API    |    Version:  trunk
 Severity:  normal       |   Keywords:
  Focuses:  performance  |
-------------------------+-----------------------------
 I've been digging into the Cache API for a bit, trying to get my knowledge
 up.
 This led me to ticket #22661 and the implications it made in my mind made
 me think of another way of setting up the cache structure.

 This implementation has a few considerations and I'm honestly not sure if
 this would be the best way to do it but I wanted to share and get some
 opinions about it.

 The theory behind the extended code is the following:
 When multiple layers of cache are possible then each layer can be used for
 a much more specific task and gives a lot more control and can remove a
 lot of dependency of one implementation.

 You could think of having a separate cache handler for post objects,
 session data or other groups. This way you can 'more safely' restart or
 flush cache services.

 The lines that Mark wrote about 'it cannot gracefully degrade to the
 built-in object cache' led to, what I think, is the only implementation
 that would allow this on a bigger scale then Mark originally meant. A
 possible degradation catch on each single cache request.

 '''Considerations'''
 * Cache will be stored on more "locations" thus consuming more memory.
 * Setting cache will take more time (relatively speaking).
 * Retrieving cache that isn't present everywhere will take more time
 depending on the implementation and number of handlers.
 * Setting cached data to other sources takes less time then regenerating
 this data.
 * Very limited modification of the current code structure.

 The only thing an implementation would have to do is extend the
 `WP_Object_Cache_Handler` and register it. Not implementing any of the
 Cache API functions makes it so that the system does not use the 'external
 cache'.
 Thus this will not break any current implementations.

 This is a concept I've been working on it for some time now, just to see
 how the implementation would have to work and what limitations it would
 have. I don't need to have this implemented but would like some critique
 and feedback if such a thing would be considered an improving feature.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32184>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform