diff options
author | Timo Tijhof <krinkle@fastmail.com> | 2024-09-10 17:26:00 -0700 |
---|---|---|
committer | Krinkle <krinkle@fastmail.com> | 2024-09-18 15:46:25 +0000 |
commit | 0eace3287b57a678e4a9b9dd479548c4bf954360 (patch) | |
tree | eb5eb60927ba89a977894a421a2380da1b2fd775 /tests/phpunit/unit/includes/Rest/Module | |
parent | 6731298b9f80c6640fd2e6789d36e07643c5600e (diff) | |
download | mediawikicore-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