Defer all stat increments to a job #17
Conversation
| @@ -72,29 +73,13 @@ public function increment( string $stat, int $delta, UserIdentity $user, array $ | |||
| } | |||
|
|
|||
| private function doIncrements() { | |||
| // Attempt to do it NOW. If we get an error, fall back to the SyncService job. | |||
There was a problem hiding this comment.
for posterity: the intent of this was to make sure the stats for a page edit was processed in time for the page view immediately afterwards to show the toast notifications for any achievements earned. otherwise it was kinda weird for a first-time editor to edit a page and then at some indeterminate time later when they next made a page view get that toast. but among all the jank in the current Fandom ™️ first time editor experience, this is not as huge a deal as compared to what it was on Gamepedia.
There was a problem hiding this comment.
If I was to guess this might already have been broken, since this runs in a shutdown function, by which time the user will have already been redirected after a successful edit since FPM will have flushed the response due to MediaWiki running fastcgi_finish_request as part of its request termination logic.
There was a problem hiding this comment.
Yeah, I agree, it was probably always race-y, and just got less likely to do the intended behavior over time as more stuff was being done in shutdown and as external services became more numerous.
Cheevos currently attempts to perform all stat increments in a shutdown function, enqueueing a job if this fails. This can result in excessive load on the backing service as some stats are updated on e.g. every registered user PV on GP wikis, which can in turn also overload the UCP process pool due to the synchronous update. So, always defer these stat increments to a job instead, for better concurrency control and reduced impact on user-facing process pools.
mszabo-wikia
force-pushed
the
cheevos-only-jobs
branch
from
98f347a
to
ee03386
Compare
Cheevos currently attempts to perform all stat increments in a shutdown function, enqueueing a job if this fails. This can result in excessive load on the backing service as some stats are updated on e.g. every registered user PV on GP wikis, which can in turn also overload the UCP process pool due to the synchronous update.
So, always defer these stat increments to a job instead, for better concurrency control and reduced impact on user-facing process pools.