Page MenuHomePhabricator

Improve speed of Special:Watchlist mass clearing
Open, LowPublic

Description

Per T222533, The speed of clearing Special:Watchlist via /raw and /clear should be improved so a change is applied immediately similar to /edit rather than going through the job queue which can take significantly longer

Event Timeline

RhinosF1 created this task.May 14 2019, 5:55 PM

(Removing team tags as it is up to teams what they plan to work on.)

@RhinosF1: Unfortunately this report lacks some information. What do you expect to see? What do you see currently? Which specific criteria to apply which allow judging whether this task is done and successfully resolved at some point? Unspecific "make everything faster somehow" tasks are not helpful. :)

RhinosF1 added a comment.EditedMay 16 2019, 6:24 PM

(Removing team tags as it is up to teams what they plan to work on.)

Copied exactly from parent task - Based on discussion there adding Core Platform Team seems appropriate

@RhinosF1: Unfortunately this report lacks some information. What do you expect to see? What do you see currently? Which specific criteria to apply which allow judging whether this task is done and successfully resolved at some point? Unspecific "make everything faster somehow" tasks are not helpful. :)

! In T222533#5168793, @MMiller_WMF wrote:

@RhinosF1 -- would you say that the larger issue is that the watchlist takes a long time to clear, or that the user doesn't have any warning that it will take a long time? The latter is obviously faster and easier to fix than the former.

! In T222533#5182114, @JTannerWMF wrote:

We will fix the message on this, however the speed is not within scope of this team. We believe the Core Platform Team would be responsible for the speed. We will use this Phab task for the message and Core Platform Team can use another for the speed.

See the above posts from the parent task that is being used to add a message alerting users temporarily while Core Platform Team improve the performance of clearing through an improved system

RhinosF1 updated the task description. (Show Details)May 16 2019, 6:38 PM

@RhinosF1: You seem to have posted a few comments from the other task, but no answer to my question?

@RhinosF1: You seem to have posted a few comments from the other task, but no answer to my question?

Essentially, it's per the parent task. See there but the TL;DR Is going through a job queue takes a long time and it can be rebuilt to not use that which will be quicker. The taks is resolved when as you click save the changes happen ideally. What do I see/expect is answered in the parent task.

What do I see/expect is answered in the parent task.

@RhinosF1: It should be summarized and answered here (in the task description) so people don't have to read through discussions in some other task, including clear objective criteria that allow defining when to call this task resolved.

What do I see/expect is answered in the parent task.

@RhinosF1: It should be summarized and answered here (in the task description) so people don't have to read through discussions in some other task, including clear objective criteria that allow defining when to call this task resolved.

@Aklapper : It does now - Is this comment general or aimed at this task? Ping me on IRC if you want to discuss how to format it more as it'll be quicker

Adding back into the Core Platform Team inbox so we can discuss this at our task triage meeting.

Anomie added a subscriber: Anomie.May 30 2019, 3:55 PM

I note that the job queue clearing was added specifically because the old code that did do direct clearing was too slow. It's hard to insert/update/delete hundreds of thousands of database rows.

EvanProdromou added a subscriber: EvanProdromou.

So, we on CPT think that it's essential to use the job queue for large watchlists, because older code that did the deletion directly would time out.

I think our tasks here are the following:

  • Review if there's any obvious optimization to do in the query itself
  • Review and confirm if there's any reason this job is being deprioritized (I don't think that's possible, but it's worth confirming)
  • Coordinate with Growth on T222533 so we support setting/unsetting a flag for showing a message on Special:Watchlist.

I think we should probably lead on that last part; it's not useful to show the message if the flag doesn't exist.

kostajh moved this task from Inbox to Triaged but Future on the Growth-Team board.Sep 4 2019, 9:10 AM

T222533 is on #growh-team's radar, but I don't think the other optimizations are things we'd have time to do in the short-to-medium term.

@Krinkle: Is this and T41510 not same thing?

This task is about the processing of submissions, from Special:EditWatchlist/raw and Special:EditWatchlist/clear. The main problem is that, after you're shown the list and indicated what you want to change and submit it, that processing such submission is slow.

Task T41510 is about the the displaying of the checkbox-based interface at Special:EditWatchlist. The main problem there is the expensive nature of generating that many checkboxes whilst displaying the page. It is not about processing its form submission.

I hope I got that right, and if I did, that it made sense :)

This task is about the processing of submissions, from Special:EditWatchlist/raw and Special:EditWatchlist/clear. The main problem is that, after you're shown the list and indicated what you want to change and submit it, that processing such submission is slow.
Task T41510 is about the the displaying of the checkbox-based interface at Special:EditWatchlist. The main problem there is the expensive nature of generating that many checkboxes whilst displaying the page. It is not about processing its form submission.
I hope I got that right, and if I did, that it made sense :)

Yep, makes sense now