Beta testing of the ReadingLists extension
Closed, ResolvedPublic

Description

Things that should be delayed until ReadingLists is deployed on the Beta cluster (to make it available for testing to app developers as soon as possible), but should be done before it is deployed in production:

See also T171913: Fix technical debt in ReadingLists extension and the (non-security) concerns in T174126: Security review for the ReadingLists extension.

Tgr created this task.Aug 31 2017, 8:08 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 31 2017, 8:08 AM

The main concern is the footprint per list item- it should be much lower to support large scale usage.

Tgr updated the task description. (Show Details)Aug 31 2017, 4:54 PM
Tgr added a subscriber: Mholloway.Aug 31 2017, 5:00 PM

The main concern is the footprint per list item- it should be much lower to support large scale usage.

Would that be resolved by moving rle_project to its own table, or are you worried about titles as well? I guess we could deduplicate those as well. @Mholloway do we have any data from the Android app on the level of overlap between lists (ie. total number of reading list items over all users vs. number of unique pages which appear in the reading list of some user)?

Mholloway added a subscriber: Dbrant.EditedAug 31 2017, 6:36 PM

Unfortunately we have no data on the specific articles in users' reading lists, only general data on how frequently users add or delete items or change metadata (e.g., the list description), along with the user's total number of lists, the lists' sizes, and from where they're being accessed in the app.

https://meta.wikimedia.org/wiki/Schema:MobileWikiAppReadingLists

It is ok to not do that now, and wait to see what is the regular usage in space per user and entry, and what the ways to optimize are. That would be reasonable course of action.

My only request is to not forget about this. I had instances in the past where a developer said "I will do that later" and then when things go wrong "don't have the bandwith to fix it". I do not have problems with how it is now, but as a warning, I will block further updates if the table grows over 300GB -or before, if it causes server problems-, so it is not forgotten. I just want someone to be responsible and reactive if problems arise (which normally don't until peak usage), I hope you understand my fears.

Tgr claimed this task.Sep 1 2017, 9:07 AM
Tgr updated the task description. (Show Details)Oct 5 2017, 8:56 AM

Change 384908 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[operations/mediawiki-config@master] Deploy ReadingLists to the beta cluster

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

Change 384909 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/tools/release@master] Add ReadingLists extension

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

Tgr updated the task description. (Show Details)Oct 17 2017, 11:57 PM

Change 384908 merged by jenkins-bot:
[operations/mediawiki-config@master] Deploy ReadingLists to the beta cluster

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

Mentioned in SAL (#wikimedia-operations) [2017-10-18T22:27:51Z] <tgr@tin> Synchronized wmf-config/: T174651 / gerrit 384908 - deploy ReadingLists to beta - noop for production (duration: 00m 53s)

Change 384909 merged by jenkins-bot:
[mediawiki/tools/release@master] Add ReadingLists extension

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

Tgr moved this task from Backlog to Coming soon on the Reading List Service board.Dec 6 2017, 12:40 AM
Tgr updated the task description. (Show Details)Dec 6 2017, 1:03 AM
Tgr closed this task as Resolved.
Tgr updated the task description. (Show Details)Dec 6 2017, 1:05 AM