Defer building new filters menu to speed up performance
Closed, ResolvedPublic

Description

There is a slow down in the time it takes to load recentchanges reported by users in hewiki following the new edit filters.

This should be evaluated (if not already done) - though I couldn't find a specific board for it in grafana.
Here is my personal crappy evaluation as anonymous user (to avoid loading specific user scripts)

  • Firefox 55: contentLoaded 1.43s-1.61s, load: 6.7s-7.6s (3 tries)
  • Chromium 60.0.3112: content loaded: 215ms-748ms, load: 462ms-1.23s (3 tries)

Sometimes it can even get as high as 18s to load in FF.

Compared to some random wiki page (not RC):

  • Firefox: contentLoaded 820-850ms, load: 2.40-2.60s (3 tries)
  • Chromium: content loaded: 150-362ms load: 335-384ms

Suggestion:
Don't use jquery.ready when DOMContentLoaded is sufficient. (see example for this magic in ULS: https://gerrit.wikimedia.org/r/#/c/299285/ ).

Specifically I would recommend to check carefully this line in mw.rcfilters.init.js:

$( rcfilters.init );
eranroz created this task.Sep 19 2017, 7:10 PM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptSep 19 2017, 7:10 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Krinkle updated the task description. (Show Details)Sep 19 2017, 9:12 PM

@eranroz, are you sure it's Recent Changes where the slowdown occurred? Hebrew beta users have been looking at that for months and reported no slowdowns.

On the other hand, we just launched the New Filters beta to Watchlist today. Is that the slowdown you've seen reports about?

I think he likely did mean RC, because he's a hewiki user and we launched RCFilters as a default there today.

Change 379117 had a related patch set uploaded (by Eranroz; owner: Eranroz):
[mediawiki/core@master] Lazy creation for heavy menu

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

eranroz added a comment.EditedSep 19 2017, 10:12 PM

It looks like the RC sometimes very slow to load.

  1. The above patch address only some of the slowness (the hidden UI creation can take ~1sec)
  2. Ideally there should be a performance metrics for RCFilters. How long does it take till the RC is fully loaded before this change and after this change?

<s>3. This could be also a operation issue: There are some requests with 404 response during load:
https://he.wikipedia.org/wiki/%D7%9E%D7%99%D7%95%D7%97%D7%93:%D7%A9%D7%99%D7%A0%D7%95%D7%99%D7%99%D7%9D_%D7%90%D7%97%D7%A8%D7%95%D7%A0%D7%99%D7%9D?hidebots=1&hidecategorization=1&hideWikibase=1&limit=1&days=7&urlversion=2&from=20170919220833&action=render&enhanced=0

Bad response from the following servers:
mw1216.eqiad.wmnet
mw1265
mw1241
mw1269
mw1245

Good response from:
mw1238
</s>

I am looking at he.wiki Recent Changes page. With default filters but set to return 500 results from 30 days, I see delay of about 3-4 seconds. Which is to say virtually identical to what I see when I test the old UX.

@eranroz, what combinations are giving you a 404? (The link you provide takes me to a version of the page that I don't recognize.)

Catrope added a comment.EditedSep 19 2017, 10:25 PM

It looks like the RC sometimes very slow to load.

  1. The above patch address only some of the slowness (the hidden UI creation can take ~1sec)

Thanks! It looks good to me but I'll let @Mooeypoo make the final call, she wrote most of that code.

  1. Ideally there should be a performance metrics for RCFilters. How long does it take till the RC is fully loaded before this change and after this change?

Yes, there should be.

<s>3. This could be also a operation issue: There are some requests with 404 response during load:

For some strange reason, 404s are "expected behavior" when there are no results to your RC query.

I am looking at he.wiki Recent Changes page. With default filters but set to return 500 results from 30 days, I see delay of about 3-4 seconds. Which is to say virtually identical to what I see when I test the old UX.

@eranroz, what combinations are giving you a 404? (The link you provide takes me to a version of the page that I don't recognize.)

Please ignore the above comment about 404. (there is a periodic query on the recent changes with "from" parameter from last load, giving all the changes since then, and when there are no changes it returns 404 - this is valid behaviour)

There's another area for improvement that @Mooeypoo has been working on: T173533: No longer block user from clicking results when page is loading.. Currently, we show a loading animation and an overlay over the results while the UI is loading, but we should really just let the user interact with the results list right away. The reason we currently do this is because in some cases (if the user has a saved query that they've made default), we may need to reload the result list and replace it with the result of a different query, because default saved queries are handled entirely client-side. Moriel is working on moving this server-side (T166908: ChangesListSpecialPage backend: Respect saved query if no parameters) and after that's done we can remove the loading thing from the results list.

However, we could expedite this by optimizing for the most common case: if the user doesn't have a default saved query (which is probably the most common case), add (or don't add) a CSS class that causes the loading effect not to appear, and if they do, add a different CSS class. That way we don't have to wait for T173533 to be done before improving the experience for most people.

There's another area for improvement that @Mooeypoo has been working on: T173533: No longer block user from clicking results when page is loading.. Currently, we show a loading animation and an overlay over the results while the UI is loading, but we should really just let the user interact with the results list right away. The reason we currently do this is because in some cases (if the user has a saved query that they've made default), we may need to reload the result list and replace it with the result of a different query, because default saved queries are handled entirely client-side. Moriel is working on moving this server-side (T166908: ChangesListSpecialPage backend: Respect saved query if no parameters) and after that's done we can remove the loading thing from the results list.

However, we could expedite this by optimizing for the most common case: if the user doesn't have a default saved query (which is probably the most common case), add (or don't add) a CSS class that causes the loading effect not to appear, and if they do, add a different CSS class. That way we don't have to wait for T173533 to be done before improving the experience for most people.

Thanks for pointing out to these these tasks - very good ideas and will solve the slowness issues much better than what I suggested (I was lucky to avoid edit conflict here :))

Stryn added a subscriber: Stryn.Sep 20 2017, 4:51 AM

I am looking at he.wiki Recent Changes page. With default filters but set to return 500 results from 30 days, I see delay of about 3-4 seconds. Which is to say virtually identical to what I see when I test the old UX.

@jmatazzoni : FYI, on en.wp.org,

  • full refresh page load time with JS disabled for the watchlist is 2.2 seconds [old UI loaded]
  • full refresh page time load with JS enabled is 6.02 seconds
  • normal refresh page time load with JS enabled is 4.34 seconds.

India/Chrome/Linux.

Change 379117 merged by jenkins-bot:
[mediawiki/core@master] Lazy creation for heavy menu

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

Change 379431 had a related patch set uploaded (by Catrope; owner: Eranroz):
[mediawiki/core@wmf/1.30.0-wmf.19] Lazy creation for heavy menu

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

Change 379431 merged by jenkins-bot:
[mediawiki/core@wmf/1.30.0-wmf.19] Lazy creation for heavy menu

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

Mentioned in SAL (#wikimedia-operations) [2017-09-21T00:02:29Z] <catrope@tin> Synchronized php-1.30.0-wmf.19/resources/src/mediawiki.rcfilters/: Lazy-load the RCFilters menu (T176250) (duration: 00m 48s)

He7d3r added a subscriber: He7d3r.Sat, Sep 23, 6:43 PM
jmatazzoni renamed this task from Slowdown due to new filters to Defer building new filters menu to speed up performance.Mon, Sep 25, 8:05 PM

Checked RC page load time (and Watchlist page) in betalabs and testwiki (1.31.0-wmf.1 ). The load time is from 2s to 4.40s (testwiki).

The extreme load times (7s - 18s) were not observed. The task required re-checking in production on enwiki. I saved several tests done on www.webpagetest.org to compare with production data.

Krinkle removed a subscriber: Krinkle.Wed, Sep 27, 3:57 PM

Re-checked in 1.31.0-wmf.1 - the performance for RC and Watchlist pages seem to be improved.

Etonkovidova closed this task as Resolved.Fri, Sep 29, 12:38 AM