[wp-trac] [WordPress Trac] #31094: Attempt to cache notoptions in database to save queries for non-existent options

[WordPress Trac]

#31094: Attempt to cache notoptions in database to save queries for non-existent
options
----------------------------------------+------------------------------
 Reporter:  ashfame                     |       Owner:
     Type:  enhancement                 |      Status:  new
 Priority:  normal                      |   Milestone:  Awaiting Review
Component:  Options, Meta APIs          |     Version:
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:
----------------------------------------+------------------------------
Changes (by boonebgorges):

 * keywords:  has-patch dev-feedback needs-unit-tests => has-patch needs-
     unit-tests


Comment:

 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.

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