[wp-trac] [WordPress Trac] #57906: Introduce `wp_cache_*_query()` helpers
WordPress Trac
noreply at wordpress.org
Fri Mar 10 23:08:03 UTC 2023
#57906: Introduce `wp_cache_*_query()` helpers
-------------------------+-----------------------------
Reporter: tillkruess | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Cache API | Version: trunk
Severity: normal | Keywords:
Focuses: |
-------------------------+-----------------------------
Ticket #57625 outlines the issue of the `last_changed` timestamp of cache
groups changing often, resulting in new cache keys for the same query,
while not (or only slowly) expiring old keys. On busy sites this can be
large amounts of cache data.
Giving object cache implementation more information about cached queries
and sql results could make deleting stale cache keys much more efficient
for each individual backend.
Take this example:
{{{#!php
<?php
$query = "SELECT p.ID FROM $wpdb->posts AS p $join $where $sort";
$key = md5( $query );
$last_changed = wp_cache_get_last_changed( 'posts' );
if ( $in_same_term ) {
$last_changed .= wp_cache_get_last_changed( 'terms' );
}
$cache_key = "adjacent_post:$key:$last_changed";
$result = wp_cache_get( $cache_key, 'posts' );
}}}
The cache key `adjacent_post:eecd152a77156d10fff6090cd03144c1:0.63115800
16784882730.54921700 1678488360` is pretty useless to an implementation.
Introducing a new helper `wp_cache_get_latest()` would give an object
cache more to work with to perform near instant invalidation, even with 10
of millions of keys:
{{{#!php
<?php
$query = "SELECT p.ID FROM $wpdb->posts AS p $join $where $sort";
$key = md5( $query );
$last_changed = array( wp_cache_get_last_changed( 'posts' ) );
if ( $in_same_term ) {
$last_changed[] = wp_cache_get_last_changed( 'terms' );
}
$result = wp_cache_get_query( $key, $last_changed, 'adjacent_post',
'posts' );
}}}
This would tell the object cache:
- The query hash `$key`
- The last changed timestamp to delete older data only
- The type `adjacent_post`, so `wp_query` of the same `posts` group
doesn't need to be flushed
And the implementation can store these in a hash or sorted set, which
makes invalidation instantaneous and low cost.
Making this a progressive enhancement is cheap and easy:
{{{#!php
<?php
function wp_cache_get_query( $key, $last_changed, $type, $group ) {
$last_changed = implode( '', $last_changed );
return wp_cache_get( "$type:$key:$last_changed", $group );
}
function wp_cache_set_query( $key, $value, $last_changed, $type, $group )
{
$last_changed = implode( '', $last_changed );
return wp_cache_set( "$type:$key:$last_changed", $value, $group );
}
}}}
--
Ticket URL: <https://core.trac.wordpress.org/ticket/57906>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list