Page MenuHomePhabricator

Systematically test load speeds of Watchlist and Recent Changes
Closed, DeclinedPublic


To get a handle on whether and how much the New Filters are slowing down Watchlist and Recent Changes, we will make tests and publish them to a wiki page.

Testing Plan

Results will be the average of 5 page loads
All tests to be performed

  1. for Recent Changes and Watchlist both
  2. with cold cache versus hot cache both
  3. On English Wikipedia (which, as the biggest, should show up any differences the most)

Test on old and new UX for comparison

  • Default filter sets (see below).
  • Default filter sets + "Experienced users", "Learners", "#Blanking" and ":User talk" (intended to see if adding more standard filters makes a difference).

Test new UX only

  • "Typical" ORES filter set" (see below)
  • "Rare" (slower) ORES filter set" (see below)

Results table example

To clarify the various tests involved, I prepared a results table that can be a model for how the results might be published.

Typical ORES filter set

Rare ORES filter set (note short search period and low result limit)

Current Default Settings

The following are the pre-New Filters default preferences for RC and WL. The preferences here are described as they will be implemented in the New Filters UX, except for those that do not exist in the new UX and will continue to be presented on the Preferences page.

Recent Changes
  • 7 days, 50 results.
  • Active filters = Logged edits, page creations, page edits, human (not bot)
Watchlist ( existing defaults)
  • 3 days, 250 maximum results
  • Active filters: Latest revision, Logged edits, page creations, page edits. [Note: unlike RC page, “Human (not bot)” is NOT a default]
  • Active WL pref page options: "Add pages I create and files I upload to my watchlist", "Add new files I upload to my watchlist"

Event Timeline

@Catrope, you signed yourself up to create a way to turn off Live Update. Whoever is taking on this task should be able to get going without that, but please coordinate with whomever you assign.

@Catrope, you signed yourself up to create a way to turn off Live Update. Whoever is taking on this task should be able to get going without that, but please coordinate with whomever you assign.

I ended up convincing @SBisson to make that kill switch instead, because he was already going to touch other stuff in the LU area.

Roan pointed out that turning Live Update off and on should not affect the different UIs differently, so that element has been removed from testing. If we think we need to test whether Live Update is slowing everything down. We'll have to make a time when we can do that for an entire site.

enwiki (wmf.3) testing the 'Rare ORES filter set' test query:

got [WeUxIQpAIDMAAF3faqwAAAAH] 2017-10-16 22:23:25: Fatal exception of type "Wikimedia\Rdbms\DBQueryTimeoutError"
Looking at the

reqId	   	WeUxIQpAIDMAAF3faqwAAAAH
shard	   	s1

SELECT  /*! STRAIGHT_JOIN */ rc_id,rc_timestamp,rc_user,rc_user_text,rc_namespace,rc_title,rc_minor,rc_bot,rc_new,rc_cur_id,rc_this_oldid,rc_last_oldid,rc_type,rc_source,rc_patrolled,rc_ip,rc_old_len,rc_new_len,rc_deleted,rc_logid,rc_log_type,rc_log_action,rc_params,rc_comment AS `rc_comment_text`,NULL AS `rc_comment_data`,NULL AS `rc_comment_cid`,wl_user,wl_notificationtimestamp,page_latest,(SELECT  GROUP_CONCAT(ct_tag SEPARATOR ',')  FROM `change_tag`    WHERE ct_rc_id=rc_id  ) AS `ts_tags`,fp_stable,fp_pending_since,ores_damaging_cls.oresc_probability AS `ores_damaging_score`,ores_goodfaith_cls.oresc_probability AS `ores_goodfaith_score`  FROM `recentchanges` LEFT JOIN `watchlist` ON (wl_user = '22858399' AND (wl_title=rc_title) AND (wl_namespace=rc_namespace)) LEFT JOIN `page` ON ((rc_cur_id=page_id)) LEFT JOIN `flaggedpages` ON ((fp_page_id = rc_cur_id)) LEFT JOIN `ores_model` `ores_damaging_mdl` ON (ores_damaging_mdl.oresm_is_current = '1' AND ores_damaging_mdl.oresm_name = 'damaging') LEFT JOIN `ores_classification` `ores_damaging_cls` ON ((ores_damaging_cls.oresc_model = ores_damaging_mdl.oresm_id) AND (rc_this_oldid = ores_damaging_cls.oresc_rev) AND ores_damaging_cls.oresc_class = '1') LEFT JOIN `ores_model` `ores_goodfaith_mdl` ON (ores_goodfaith_mdl.oresm_is_current = '1' AND ores_goodfaith_mdl.oresm_name = 'goodfaith') LEFT JOIN `ores_classification` `ores_goodfaith_cls` ON ((ores_goodfaith_cls.oresc_model = ores_goodfaith_mdl.oresm_id) AND (rc_this_oldid = ores_goodfaith_cls.oresc_rev) AND ores_goodfaith_cls.oresc_class = '1')   WHERE (rc_bot = 0) AND (rc_type != '3') AND (rc_type != '6') AND (rc_source != 'wb') AND ((ores_damaging_cls.oresc_probability BETWEEN 0.828 AND 1)) AND (rc_type NOT IN ('3','5')) AND ((ores_goodfaith_cls.oresc_probability BETWEEN 0.569 AND 1)) AND (rc_type NOT IN ('3','5')) AND (rc_timestamp >= '20171013222225') AND rc_new IN ('0','1')   ORDER BY rc_timestamp DESC LIMIT 50

50 changes is not very realistic for RC, especially if you are using the enhanced RC/WL Javascript collapsing.

Secondly, it would be good to profile ORES (damage profile) and Wikidata load times, either here or elsewhere.