WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 5 years ago

Last modified 5 years ago

#32184 closed enhancement (invalid)

Extended cache control

Reported by: jipmoors Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Cache API Keywords: has-patch dev-feedback needs-testing
Focuses: performance Cc:

Description

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.

Attachments (1)

32184-cache_via_cache_control.diff (33.4 KB) - added by jipmoors 7 years ago.
Cache Control

Download all attachments as: .zip

Change History (5)

@jipmoors
7 years ago

Cache Control

#1 @jipmoors
6 years ago

@markoheijnen this is the patch I mentioned

#2 @johnbillion
6 years ago

  • Keywords has-patch dev-feedback needs-testing added
  • Version trunk deleted

#3 @jipmoors
5 years ago

  • Resolution set to invalid
  • Status changed from new to closed

The implications are big, memory consumption high and there aren't many real world examples of this being a real issue.

#4 @ocean90
5 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.