WordPress.org

Make WordPress Core

#23059 closed defect (bug) (wontfix)

if object cache entry for last_changed in term and comments groups is purged, it invalidase too many cached items

Reported by: mark-k Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5
Component: Cache API Keywords:
Focuses: Cc:

Description

Some context to explain the issue - I was trying to be smart and cache menu generation by setting my own object temporary object caching just before the outputing the menu and saving the resulting cache to an option. On next page load I populated the cache for the option before outputting the menu.
It didn't work.

After some digging I found out that the cache key for the menu terms composed as "get_terms:$key:$last_changed" and that the $last_changed part was different in every run. So I went an looked how it is set and everything became clear

	$last_changed = wp_cache_get('last_changed', 'terms');
	if ( !$last_changed ) {
		$last_changed = time();
		wp_cache_set('last_changed', $last_changed, 'terms');
	}

Because I am running without object cache before the menu code is executed $last_changed changes every run.

This might be an edge case, but IMO it means that whenever 'last_changed' is purged/garbage collected all the terms related cached values are practically invalidated as well.

I really don't understand why the value is part of the cache key at all, but if it has to be shouldn't it be stored in a less volatile storage?

related #22024. It is closed but I think that change also doesn't handle well the situation where last_changed for comments is purged

Change History (4)

comment:1 johnbillion16 months ago

  • Cc johnbillion added

comment:2 follow-up: ryan16 months ago

This might be an edge case, but IMO it means that whenever 'last_changed' is purged/garbage collected all the terms related cached values are practically invalidated as well.
I really don't understand why the value is part of the cache key at all, but if it has to be shouldn't it be stored in a less volatile storage?

Invalidating the caches is the entire purpose of last_changed. When anything term related is changed, last_updated is bumped and all term related query caches are passively invalidated as a result. Caches with old last_updated values will eventually be pushed out of the cache and garbage collected.

comment:3 in reply to: ↑ 2 mark-k16 months ago

Replying to ryan:

Invalidating the caches is the entire purpose of last_changed. When anything term related is changed, last_updated is bumped and all term related query caches are passively invalidated as a result. Caches with old last_updated values will eventually be pushed out of the cache and garbage collected.

  1. Right now it invalidates too much. In my case it simply rendered object caching useless
  1. In practice it doesn't invalidate, as the value is set only once and unless it is purged from the cache by the caching software itself the value never changes no matter how many term related changes where done.

comment:4 ryan14 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

The terms last_changed invalidates only the get_terms() cache.

The caching software handles eventual purging.

We do this passive invalidation in several places. See #23173 for why.

Caching this query but not last_changed or anything else is very edge.

Note: See TracTickets for help on using tickets.