WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#31094 new enhancement

Attempt to cache notoptions in database to save queries for non-existent options

Reported by: ashfame Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Options, Meta APIs Keywords: has-patch needs-unit-tests
Focuses: Cc:

Description

Coming from #31061, @boone suggested this might be worth exploring, so I took a first pass at it.

Idea is to save nonexistent options in options table as notoptions_cache. This seems to be working nicely so far. Non existent queries get cached, and gets refreshed when they are added or updated.

I am considering the following moving forward:

1) Upon delete_option() call, we can add that option to notoptions_cache right away but I can imagine cases where we wouldn't want that, so I believe letting it get added on get_option() is a better choice
2) Implement it for Multisite functions - Should we? Chances are anyone who is running a multisite is already using a persistent object cache backend. Thoughts?
3) If object-cache.php is dropped in, so notoptions cache is now maintained over there persistently, all good. But when its moved out, it will try to use the notoptions_cache inside option table which may not be accurate anymore, so we need to delete it the moment a persistent object cache backend gets involved.

Thoughts? Anything else I should consider?

Attachments (2)

trac-31094.diff (4.3 KB) - added by ashfame 3 years ago.
First pass
trac-31094-pass2.diff (4.4 KB) - added by ashfame 3 years ago.
pass2, added another condition

Download all attachments as: .zip

Change History (8)

@ashfame
3 years ago

First pass

@ashfame
3 years ago

pass2, added another condition

This ticket was mentioned in Slack in #core by ashfame. View the logs.


3 years ago

#3 @ashfame
3 years ago

  • Keywords has-patch dev-feedback needs-unit-tests added

#4 @SergeyBiryukov
3 years ago

  • Component changed from Cache API to Options, Meta APIs

#5 @boonebgorges
3 years ago

  • Keywords dev-feedback removed

Thanks for getting this conversation started, ashfame.

Seems that we could simplify the internal logic and eliminate your problem (3) by removing the wp_using_ext_object_cache() checks, and storing the 'notoptions' keys in the options table no matter what. In cases where an object cache is being used, this will result in a small amount of overhead, since the keys will be stored in memory twice. But I think it's probably negligible.

Regarding site options: since they support the notoptions cache, I'd say they should get the same fix. I for one have a number of clients running multisite instances without a persistent cache :)

Agreed on your delete_option() analysis.

What's the reasoning for using $wpdb->insert() to add the 'notoptions_cache' option, instead of add_option()?

The following two things would be really helpful to move this ticket forward:

  • Unit tests that demonstrate invalidation of the new cache on update_option() and add_option()
  • Benchmarks (load time, CPU usage, memory usage, number of database queries) with and without the patch, on a standard installation (without a persistent cache, of course). As long as these numbers are significant - and I assume that they will be - it'll make the case for this improvement much more convincing.

#6 @georgestephanis
3 years ago

A couple thoughts:

  • Should each notoption include an expiration, so notoptions doesn't get huge over time and legacy notoptions persist for all eternity, long since the plugin/theme that cared about them has been deactivated?
  • Should we maybe delay the update_option() call until late in the game, so if ten notoptions get added on a given request, it only triggers one db write?
  • Could this be written more easily as a plugin rather than a core patch, for testing and experimenting -- as well as use should it get rejected for core?
  • Should there be a special filter on option_notoptions? Maybe a function is_not_option() or something. Iunno, at this point I think I'm just rambling.

All in all, I like the idea, I just feel like there's a problem with it in the back of my mind that I just can't quite remember.

Note: See TracTickets for help on using tickets.