Further caching fix - use metadata cache

[eileenmcnaughton]

Overview

Further caching fix - use metadata cache

Before

This cache access construct
$optionValues = CRM_Utils_Cache::singleton()->get($cacheKey);`

After

Uses

  if (Civi::cache('metadata')->has($cacheKey)) {
      return Civi::cache('metadata')->get($cacheKey);
    }

Technical Details

This is a performance fix - for Redis users the current method never uses the array cache whereas the latter does. In conjunction with #24156 I got about another 10% improvement on Contact updates in our staging environment.

The data is a bit murky in prod as I accidentally undeployed the first patch when I first deployed this (where it the U goes back up again) & then when I re-deployed (where it shoots back down again) our high volume ended just as it was starting to look like this would show a clear-cut boost (those zig-zags at the end are when traffic slowed & we started working with a colder cache / less consistent run size)

Comments

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[colemanw]

One problem is that we have too many functions in CiviCRM that fetch option values, and each one has its own idea about caching.

[eileenmcnaughton]

@colemanw surely not :-)

[totten]

(@colemanw) ..[we have] many functions in CiviCRM that fetch option values...

Do we have a list somewhere? Maybe there's an OptionGroup for that...