Page MenuHomePhabricator

Separate delay and totaldelay metrics in CP
Closed, ResolvedPublic

Description

Right now for the recursive jobs we calculate the job delay from the time the first original event was published and mix that with non-recursive job delays, which shows the delay related to this particular job enqueue time. The are conceptually different and it would be more useful to separate them

Event Timeline

Change 395864 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[mediawiki/services/change-propagation/deploy@master] [Config] Update how we calculate if-unmodified-since for transclusions

https://gerrit.wikimedia.org/r/395864

Change 395864 merged by Mobrovac:
[mediawiki/services/change-propagation/deploy@master] [Config] Update how we calculate if-unmodified-since for transclusions

https://gerrit.wikimedia.org/r/395864

Mentioned in SAL (#wikimedia-operations) [2017-12-06T22:57:45Z] <ppchelko@tin> Started deploy [cpjobqueue/deploy@761524f]: Separate delay and totaldelay metrics T182216

Mentioned in SAL (#wikimedia-operations) [2017-12-06T22:58:17Z] <ppchelko@tin> Finished deploy [cpjobqueue/deploy@761524f]: Separate delay and totaldelay metrics T182216 (duration: 00m 31s)

The metric was splitter and we've got a new graph: https://grafana.wikimedia.org/dashboard/db/jobqueue-eventbus?orgId=1&panelId=6&fullscreen

It will look pretty weird today as we're still processing the duplicates we've created transferring htmlCacheUpdate.

Resolving. The same feature will get to ChangeProp when we next deploy it