Page MenuHomePhabricator

Re-enable per-filter profiling on wikis where it was disabled
Closed, ResolvedPublic

Description

With T101648 (June 2015) per-filter profiling was removed because it was slowing down the saving of edits. @dmaza did some fantastic investigation and it looks like since that time, the code was reworked so that the profiling happened after the edit was saved. This hopefully means we are safe to re-enable the profiling on wikis where it was removed, as this feature was hugely helpful and is sorely missed.

Relevant commit that deferred the profiling to after the edit was saved: rEABF43a538fe (April 2016)

We now have a Grafana dashboard showing overall AbuseFilter runtimes, so we could perhaps use that to see if the per-filter profiling is slowing anything down. I thought the Portuguese Wikipedia would be a good one to start with, as it has a lot a filters and is big enough to provide meaningful data, but is not quite as risky as enwiki.

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 28 2017, 7:40 PM

Pinging @aaron who authored the April 2016 commit, and @He7d3r who created T101648 and is also an active filter manager on ptwiki. What do you guys think?

MusikAnimal updated the task description. (Show Details)Sep 28 2017, 7:47 PM
dmaza added a comment.Sep 28 2017, 8:06 PM

I suggest that we enable the overall profiling on the Portuguese wiki for a few hours/days before we turn on the per-filter profiling to have a good baseline to compare.

If everything works like we are expecting, the work needed on T174205 can be easily added to the per-filter profiling logic.

aaron added a comment.Oct 2 2017, 9:45 PM

I think it's fine to roll out there as long as you are watching https://grafana.wikimedia.org/dashboard/db/save-timing?refresh=5m&orgId=1 and check the -index.svg flamegraph at https://performance.wikimedia.org/xenon/svgs/daily/ for day of deployment the next day (current day values are always useless/incomplete).

@aaron — Is there anything in particular we should look for on the flamegraphs? Or just visually check that it isn't massively different from the day(s) before? These three look similar, so we can't really tell if there's anything notable:

aaron added a comment.Oct 3 2017, 9:15 PM

I'd look for the new method calls that are being reached and whether they show up and how large their profile is if they do. Note that you can use cntl-F on the svg images to highlight matches in purple.

If you look under MediaWiki::performAction -> SubmitAction::show -> EditPage::doAttemptEdit, you can see the main edit path (synchronous). I don't think deferred updates show up in there, which is too bad. We track the rate but not the average runtime in statsd.

TBolliger set the point value for this task to 1.Oct 6 2017, 6:15 PM
TBolliger removed the point value for this task.

@MusikAnimal are there other wikis where this feature was disabled and should be activated again, or are we done with this task?

MusikAnimal closed this task as Resolved.Apr 4 2018, 3:47 PM
MusikAnimal claimed this task.

@MusikAnimal are there other wikis where this feature was disabled and should be activated again, or are we done with this task?

I'm not sure. I'm guessing it originally was on every wiki. That being said T191039 would supersede this task, so I think we're done here. Thanks