Page MenuHomePhabricator

QueryMessageGroups is very slow on meta.wikimedia.org
Closed, ResolvedPublic

Description

The linked URL takes about ten seconds to load. Before it is loaded, group status selector nor group selection is shown nor possible.


Version: master
Severity: normal
URL: http://meta.wikimedia.org/w/api.php?action=query&format=jsonfm&meta=messagegroups&mgformat=tree&mgprop=id%7Clabel%7Cdescription%7Cicon%7Cpriority%7Cprioritylangs%7Cpriorityforce%7Cworkflowstates&mgiconsize=32
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54672

Details

Reference
bz53748

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 22 2014, 1:49 AM
bzimport set Reference to bz53748.
bzimport added a subscriber: Unknown Object (MLST).

sec KB args
12,48 32,5 id|label|description|icon|priority|prioritylangs|priorityforce|workflowstates
9,19 20 id|label|description|icon|priority|prioritylangs|priorityforce
6,19 19 id|label|description|icon|priority|prioritylangs
1,29 15,5 id|label|description|icon|priority
0,91 15,1 id|label|description|icon
0,8 15,1 id|label|description
0,92 10,4 id|label

  • Bug 55841 has been marked as a duplicate of this bug. ***

any info on this? Right now it's impossible to use the translate extension for central notice (since the selector never appears and I can't mark anything as published to push over) and I'm having to manually copy translations over. Tried on both Chrome and Firefox and it seems the url is just timing out in the end.

Thanks for documenting this, James. I'll make it a priority in the next sprint of WMF LangEng that starts next Tuesday, 2013-11-26.

Thanks for the quick response Siebrand good luck!

Ran the URL 3 times. Results:

  1. time-out. Error: 503, Service Unavailable at Mon, 25 Nov 2013 22:19:52 GMT
  2. time-out. Error: 503, Service Unavailable at Mon, 25 Nov 2013 22:21:47 GMT
  3. time-out.

Other wikis using status:
On www.wikidata.org: 1.79, 2.19, 2.06
On commons.wikimedia.org: 1.50, 1.56, 1.45

mediawiki.org (not using status): 0.97, 0.86, 0.64

This issue is tracked in mingle at https://mingle.corp.wikimedia.org/projects/internationalization/cards/3854

Change 97892 had a related patch set uploaded by Nikerabbit:
Add some profiling for bug 53748

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

Change 97892 merged by jenkins-bot:
Add some profiling for bug 53748

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

Change 97918 had a related patch set uploaded by Nikerabbit:
TUX refactoring for performance

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

Thanks, it's great to see this moving - as mentioned in October on https://bugzilla.wikimedia.org/show_bug.cgi?id=55841 , it's a considerable drag for banners with a large number of translations.

Meta user PiRSquared17 pointed out yesterday that this issue can be circumvented by disabling TUX, appending &tux=0 to the URL. I just verified this with one of the examples from bug 55841: For [1], the problem continues to occur (the workflow state selector is missing, or might only appear after a long delay), but on [2] (same page in the old interface with TUX disabled), the state selector is displayed right away and the translation's status can be changed without delay.

[1] https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=Centralnotice-tgroup-FDCpropreview20133_v1&language=ru&filter=&action=proofread&tux=1

[2] https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=Centralnotice-tgroup-FDCpropreview20133_v1&language=ru&filter=&action=proofread&tux=0

Change 98095 had a related patch set uploaded by Nikerabbit:
Replace loop with array lookup in TranslateMetadata::get

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

Change 98095 merged by jenkins-bot:
Replace loop with array lookup in TranslateMetadata::get

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

Change 97918 merged by jenkins-bot:
TUX refactoring for performance

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

Code was just deployed on Wikimedia wikis, and things work as expected now.