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

[ashfame]

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?

[ashfame]

First pass

[ashfame]

pass2, added another condition

[ashfame]

Github link - ​https://github.com/ashfame/WordPress/compare/trac_31094_notoptions_db_cache?expand=1

[boonebgorges]

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.

[georgestephanis]

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.