[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