[wp-trac] [WordPress Trac] #31245: Replace alloptions with a key cache

[WordPress Trac]

#31245: Replace alloptions with a key cache
-------------------------------------+-----------------------------
 Reporter:  rmccue                   |       Owner:  SergeyBiryukov
     Type:  enhancement              |      Status:  reviewing
 Priority:  normal                   |   Milestone:  Future Release
Component:  Options, Meta APIs       |     Version:  2.1
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  performance
-------------------------------------+-----------------------------

Comment (by dd32):

 Replying to [comment:82 SergeyBiryukov]:
 > One option that comes to mind is implementing [attachment:31245.3.diff]
 not in the hardcoded way it is in the patch, but instead hooked to
 `added_option`/`updated_option`/`deleted_option`, as demonstrated in
 comment:57. That way existing object caches could choose whether to go
 with core's `wp_cache_delete( 'alloptions', 'options' )` or unhook it and
 keep their own implementation for better performance.

 That would be a cleaner way of implementing it, and wouldn't be much
 different to the current implementation since the actions run immediately
 after the cache is updated.
 I guess the difference is that this would be relegating it to object
 caches as an optimization they could add, vs adding it a a "first class
 new feature" that the object caches would be expected to implement.

 > I'm also curious about [attachment:fabian-race-fix.diff], do you have an
 opinion on that patch?
 That'll also fix some variants of the issue, especially with long-running
 processes or where options are being used as a temporary data store in
 response to "expensive" actions (ie. external HTTP calls, etc).  In an
 environment where there's heavy option writing clashes would still be
 possible, but much minimised unless they happened at the same few
 milliseconds as mentioned earlier.
 It'd also remove the possibility of a sudden DB read influx of the other
 approach.

 This seems like the safest option here that will have an impact while also
 reducing the side effects. Probably won't fix it entirely, but will fix it
 for a not insignificant number of use-cases.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/31245#comment:83>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform