Generic tag for current issues that are causing slow server responses or slow/costly client-side payloads.
This is a form of Technical-Debt (use that workboard).
(For the workboard of the Performance Team, see Performance-Team.)
Generic tag for current issues that are causing slow server responses or slow/costly client-side payloads.
This is a form of Technical-Debt (use that workboard).
(For the workboard of the Performance Team, see Performance-Team.)
I've have some input:
Here's desktop and mobile banners where we execute our entry point code but only mount the Vuejs banner component after the 7.5 second timeout:
Good news everyone! I thought about this a bit more and ran another test to confirm/falsify my hypothesis of "all that JavaScript execution increases the TBT". I created a test banner where I wrapped our current banner in a 7.5 second timeout. It'll still be loaded by CentralNotice, increasing the Page Transfer Size (which we could avoid for repeat visitors if CN supported sending HTTP cache headers for banners, but that's outside of WMDE's control and needs a separate ticket and discussion in the WMF team that maintains Central Notice), it'll still parse the JavaScript, but the initialization code for the banner would be run outside the "measuring window" (that measures the "Time To Interactive" and then some). The results of the test look very promising: The TBT went down by almost 100ms and is now at pre-banner levels. See for yourself in the comparison of the regular banner with the timeout-banner as the baseline. The cpu.lastLongTask and cpu.totalDuration show even greater improvements. You can of course also look at the individual result of the banner with timeout
I'm going to wait to observe changes in data as this is rolled out, before closing again.
Hi @gabriel-wmde thanks for the investigation. I agree with you that it doesn't look like quick fix and I like your idea that we all need to work together.
Change #1090719 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] extension.json: set default user option for usecodemirror-colorblind
Re-opening as the exact same issue, except for the usecodemirror-colorblind preference:
Change #1090719 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):
[mediawiki/extensions/CodeMirror@master] extension.json: set default user option for usecodemirror-colorblind
Change #1052155 had a related patch set uploaded (by Umherirrender; author: Umherirrender):
[mediawiki/core@master] specials: Use batch to format comments on Special:ListFiles
Thanks everyone for the support.
@WMDE-leszek and @gabriel-wmde - There is no current assignee for this ticket and no priority set. Given the issue lies in code you all maintain, I would request you set an owner and assignee to clarify next steps here. Please let me know if you have concerns with this, but given the magnitude of the performance impact I think it's important to have clear ownership and explicit priority. Thanks
Change #868769 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/libs/CommonPasswords@master] WIP: Increase password list from 100K to 1M
Hi all -
Firstly, thank you @Peter for catching and filing this issue, and providing further clarity! And thank you @gabriel-wmde for looking into this.
Hi @gabriel-wmde , sorry for being slow on this. Ok, let me explain the performance tests:
The above patch will simplify transactions when the incoming document has no references (most image inerstions, most wikitext pastes). Simplifying transctions which involve references will be more complicated.
Change #1088581 had a related patch set uploaded (by Esanders; author: Esanders):
[VisualEditor/VisualEditor@master] newFromDocumentInsertion: Skip list replacement when new list is empty
Thanks for the comment, @awight. Good idea to load banner asynchronously, I agree with your assessment and like your proposal.
Another track for improvement would be to implement some lazy-loading. It is a shame to clone everything when we only use a fraction of the available librairies.
Change #1086572 merged by jenkins-bot:
[mediawiki/tools/phan/SecurityCheckPlugin@master] Make most remaining objects immutable
Change #1086572 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):
[mediawiki/tools/phan/SecurityCheckPlugin@master] Make most remaining objects immutable
The slow request was
The MW installer has a feature allowing the user to check a box to subscribe to mediawiki-announce. I tried to test it, since I'm doing maintenance on the client code. It timed out in the client, but the Apache logs on lists1004 show it completing successfully after 56 seconds. I got the confirmation email. I did another two requests with the same email and they each took about 57 seconds.