aboutsummaryrefslogtreecommitdiffstats
path: root/tests/phpunit/unit/includes/Rest/Module
diff options
context:
space:
mode:
authorTimo Tijhof <krinkle@fastmail.com>2024-09-10 17:26:00 -0700
committerKrinkle <krinkle@fastmail.com>2024-09-18 15:46:25 +0000
commit0eace3287b57a678e4a9b9dd479548c4bf954360 (patch)
treeeb5eb60927ba89a977894a421a2380da1b2fd775 /tests/phpunit/unit/includes/Rest/Module
parent6731298b9f80c6640fd2e6789d36e07643c5600e (diff)
downloadmediawikicore-0eace3287b57a678e4a9b9dd479548c4bf954360.tar.gz
mediawikicore-0eace3287b57a678e4a9b9dd479548c4bf954360.zip
objectcache: Remove `wanobjectcache.$keygroup.regen_set_delay` metric
Introduced in 2019 with I053a73b40d (97e0939082) as part of an optimization effort around spikes of set operations for the same keys (T203786). This has since been mitigated in other ways, with the related cool-off bounce feature removed in 2023 with Ie3a2215d33 (T321634, f83f75d3e6). As it stands, we have: * getwithset_seconds{result=hit} which effectively measures the typical memcached-get latency. * getwithset_seconds{result=miss} which effectively measures memcached-get + regen callback + memcached-set. * regen_seconds which effectively measures the regen callback. Which seems sufficient. We can also eyeball `miss - get - regen` to gauge the latency of the "set" operation, but we don't have a need to measure that precisely for every memc call in production, idem for the "get + regen" subset that regen_set_delay was measuring. Change-Id: I1c59466f0407f6b980fd04a64a7ab2e3f25c5b0d
Diffstat (limited to 'tests/phpunit/unit/includes/Rest/Module')
0 files changed, 0 insertions, 0 deletions