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

WordPress Trac noreply at wordpress.org
Fri Apr 28 23:39:22 UTC 2017


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

Comment (by johnjamesjacoby):

 [https://core.trac.wordpress.org/attachment/ticket/31245/31245.2.diff
 31245.2.diff] is my first-pass patch at using `option_name` as the cache-
 key. It includes the following changes to accomplish this:

 * A `WP_Option` class, with variables to match database columns, and magic
 methods to help with routing variable names around (I found these
 personally useful during the research/discovery/invention/transition
 phases)
 * A `WP_Option_Query` class, used to interact with the `wp_options`
 database table in a way that is more like the query classes we are
 using/building today, vs. the direct bespoke MySQL statements we've relied
 on forever previously
 * A few common helper functions for interacting with objects in key caches
 (`wp_clean_option_cache()`, etc...)
 * Usage of a new `notoptions` cache group, for queries to `wp_options` for
 options that do not exist there.

 ----

 Notables:

 * A product of all of this is the removal of the need to call
 `wp_load_alloptions()` on every call to `get_option()`. Some changes were
 made to unit tests to accommodate for this by calling it directly inside
 those offending tests. It's likely not ideal to do this in our tests, but
 the significant performance boost seems worth it to leave in for my first
 pass.
 * All other tests pass for me except
 `test_wp_get_attachment_image_should_use_wp_get_attachment_metadata` which
 somehow seems unrelated
 * I made other code changes to these and related functions, but I did try
 to be conservative and stick only to lines of code that were directly
 effected or near lines that were.
 * I've probably spent close to 100 hours massaging this patch, and I ran
 into many significant snags along the way to get this to work in a
 backwards compatible way.
 * One design compromise was to mock a `WP_Option` object to save in a new
 `notoptions` cache group. It's /easier/ (and likely makes more sense) to
 just save the `option_value`, but doing so increases the complexity of the
 logic in PHP to a degree that doesn't seem to actually make anything
 easier or better for ourselves.
 * The lack of continuity of our `pre_` filters in these functions makes it
 completely impossible to improve the `alloptions/notoptions` cache problem
 without extremely elaborate filters on `query` and so on. Normally I'd
 prefer to make a plugin as a proof-of-concept, but that is unfortunately
 impossible here as this API is coded today (and my patch does not make any
 effort to improve that, though it isn't any more difficult either.)
 * Please be open and critical, and scrutinize this deeply. I'm too close
 to the concept now to make many significant improvements to this patch
 alone, but I'm convinced that something similar to this approach is the
 ideal solution today (beyond schema changes, `wp_optionmeta`, etc...)

 Thank you in advance for taking any time to review my patch. 💜

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


More information about the wp-trac mailing list