For analytics events the timeout of 60s is way too much. I propose something much smaller, 1s perhaps?
Description
Details
Project | Branch | Lines +/- | Subject | |
---|---|---|---|---|
operations/mediawiki-config | master | +2 -2 | [EventBus] Decrease timeout and use hasty mode for analytics. |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Ottomata | T218255 Enabling api-request eventgate to group1 caused minor service disruptions | |||
Resolved | • Pchelolo | T218260 Decrease timeout for EventBus extension for analytics events |
Event Timeline
It'd be awesome if we could target 1s, but let's perhaps start with a less-aggressive number, like 5 or 10 and see how it goes.
I wonder if we should also use ?hasty=true mode for mediawiki 'analytics' events? This would use a non-ACKed producer and not ever block the MW waiting for a response.
I wonder if we should also use ?hasty=true mode for mediawiki 'analytics' events? This would use a non-ACKed producer and not ever block the MW waiting for a response.
Makes sense for analytics events IMHO
It'd be awesome if we could target 1s, but let's perhaps start with a less-aggressive number, like 5 or 10 and see how it goes.
Even during the high load the response time (when we did get a response) didn't go higher then 100ms, so I think 1 would be ok.
Change 496446 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[operations/mediawiki-config@master] [EventBus] Decrease timeout and use hasty mode for analytics.
Change 496446 merged by jenkins-bot:
[operations/mediawiki-config@master] [EventBus] Decrease timeout and use hasty mode for analytics.
Mentioned in SAL (#wikimedia-operations) [2019-03-25T19:13:14Z] <dcausse@deploy1001> Synchronized wmf-config/CommonSettings.php: T218260 (duration: 00m 49s)