May 21 2023
Sep 27 2021
Jun 23 2021
Jun 22 2021
Jun 21 2021
You just need to make sure that any code you rely on that creates EventLogging events at the end of the page lifecycle do so with pagehide/pageshow and not unload/onbeforeunload. Then we should be able to safely remove the unload handler in EventLogging's BackgroundQueue.
Indeed, it's that simple. However, @Krinkle reminded me that our JS-enabled experience now excludes IE9-10: https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix Meaning that we don't need an unload event handler at all. All grade A browsers support pagehide/pageshow according to https://caniuse.com/page-transition-events
I think that only registering the unload handler for browsers that don't support pagehide makes sense. Those older browsers don't support bfcache anyway.
Jun 15 2021
It hasn't been deployed, as far as I can see.
Jun 14 2021
Jun 10 2021
The code writing to that schema is still active in MediaWiki. I don't know if anyone is still consuming that data and in what form. It just seemed like measuring active editors is a pretty useful metric to keep. But not knowing who consumes it, if anyone, I don't have an opinion about what IP/geo context needs to be preserved.
I haven't checked what's causing the single-threaded behaviour. I presume it's happening in the evaluator, as you're probably running code on the main thread there?
I honestly have no idea, I've never looked at this data.
Jun 8 2021
Solving this with a combination of a post-send queued job and JS-issued POST requests for the DB writes sounds like a fine solution.
Jun 7 2021
Jun 1 2021
No, that's all I could find. It's not a gate, by the way, it's just best practice to have it done before deploying to production. Thank you!
May 24 2021
May 21 2021
Thank you very much for the thorough investigation and explanations, I agree that now the issue is well understood and the experiments can be removed.
May 20 2021
A starting point - and possibly the only thing to do - is to add webp to that list:
May 18 2021
I've looked at the code where the notification is created. Since you're correctly doing this in a DeferredUpdate, there shouldn't be any measurable impact on Save Timing. I don't think this extension required new metrics to be measured.
@AntiCompositeNumber pointed to the right comment. ImageMagick has limited options in that area. It's either a choice of always getting an exact width and a tiny percentage of the image being potentially cropped (what we do now) and always having the full picture but the width may vary by 1 pixel. Since the thumbnail width is expected to be a precise value in MediaWiki/wikitext, we decided to use the former.
May 17 2021
The link to the code in the task description is broken for me: https://gerrit.wikimedia.org/r/mediawiki/extensions/TheWikipediaLibrary (Not found)
Is there an easier way to test this on Beta than making 100 edits manually?
May 11 2021
Not that I know of, but that was still being debated at recent meetings
May 10 2021
May 3 2021
Apr 29 2021
Apr 28 2021
Confirmation from Michal of which code we should use: https://twitter.com/mmocny/status/1387161141097517067
Apr 27 2021
It's great that we narrowed this down and confirmed it, excellent work! The change's claimed behaviour is definitely consistant with the change we observed in hit/miss ratio. What's upstream's take on making this behaviour configurable?
Apr 26 2021
The data transfer waste is probably not that severe since HTML is gzipped and repetitive strings compress really well, but it's still waste. The Performance Team's position on these is that they serve little purpose and should be removed.
The whole system
From my perspective, yes, enough due diligence has been done on the performance front once that subtask has been completed. But the Performance Team doesn't decide what gets deployed to WMF production or not.
The data is confirmed to make it to the NavigationTiming schema for browsers that support Server-Timing:
The subtask is the only actionable left from this review.
As @AntiCompositeNumber there will always be cases where the thumbnail weighs more than the original, whenever the original uses a more compact way of storing colors (such as black and white), because our thumbnail pipeline generates true color thumbnails.
Confirming that this header now gets saved in Swift for new files:
@ema I've just realised that the net was too wide. Chrome has "Safari" in its UA string, for example: