Change 383858 had a related patch set uploaded (by Dmaza; owner: Dmaza):
[operations/mediawiki-config@master] Enable $wgAbuseFilterProfile on ptwiki

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

@Dereckson who can I ping to get a +1 from ops?

@kaldari I was told that since this "could" affect performance I need a +1 from someone at "ops" or I imagine, performace (?)
Who can I ping about this?

Change 383858 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable $wgAbuseFilterProfile on ptwiki

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

Mentioned in SAL (#wikimedia-operations) [2017-10-19T18:28:31Z] <thcipriani@tin> Synchronized wmf-config/abusefilter.php: SWAT: [[gerrit:383858|Enable $wgAbuseFilterProfile on ptwiki]] T177641 (duration: 00m 50s)

Based on the data I exported from Grafana (attached to my previous comment) I calculated the average for all the hours before 2017-10-19 at 18:00. The data is in milliseconds

75p looks inconsequential to me. ~8milliseconds delay for the 99p doesn't appear to be that significant, but it could be attributed to the fact that User:Silent modified 31 filters (!!!) shortly before or since October 19. From a purely visual judgement, there are more spikes after October 18, which could be attributed to a bad filter(s):

My initial thoughts are that re-enabling the per-filter profiling didn't affect the AbuseFilter to a noticeable degree at 75p and the evidence is too fuzzy at 99p, so it is low-risk to re-enable profiling on another wiki, which has more stable filter modification, to monitor and calculate if there is a similar change. I propose this be English Wikipedia.

@dmaza @dbarratt @kaldari @MusikAnimal @He7d3r @aaron — your thoughts?

In T177641#3713701, @TBolliger wrote:

My initial thoughts are that re-enabling the per-filter profiling didn't affect the AbuseFilter to a noticeable degree at 75p and the evidence is too fuzzy at 99p, so it is low-risk to re-enable profiling on another wiki, which has more stable filter modification, to monitor and calculate if there is a similar change. I propose this be English Wikipedia.

Based on your findings, I agree. Also because enwiki really wants the per-filter profiling! :)

Thanks to the new logstash reports of slow filters, we've already made a lot of performance improvements. I don't think we'll end up worse than where we were before those improvements, and the per-filter profiling will only make this process easier.

I've created T179323: Enable AbuseFilter per-filter profiling on English Wikipedia & monitor if there is a performance impact if we agree/decide we want to proceed.

if we enable this, I'll suggest to add the "Slow Filter" data to the per-filter profiling and stop logging the slow filters into Logstash. This way it is easy for filter editors to find such filters and improve them.

OK, let's do this. We'll take T179323 into the next AHT sprint.

In T177641#3721256, @dmaza wrote:

if we enable this, I'll suggest to add the "Slow Filter" data to the per-filter profiling and stop logging the slow filters into Logstash. This way it is easy for filter editors to find such filters and improve them.

I've made T179604: Move AbuseFilter slow filters data from Logstash to per-filter profiling to do this.