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?

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.

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:

• https://performance.wikimedia.org/xenon/svgs/daily/2017-09-30.index.svgz
• https://performance.wikimedia.org/xenon/svgs/daily/2017-10-01.index.svgz
• https://performance.wikimedia.org/xenon/svgs/daily/2017-10-02.index.svgz

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.

Once this ticket is complete, we will want to implement T179604: Move AbuseFilter slow filters data from Logstash to per-filter profiling

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