Enable on PTWP. We will then monitor the grafana logs to ensure the performance was not affected.
|operations/mediawiki-config : master||Enable $wgAbuseFilterProfile on ptwiki|
|Open||None||T209023 Major overhaul for AbuseFilter|
|Open||Daimona||T193064 Create a dedicated page for stats|
|Open||Daimona||T191428 Enhance filter profiling|
|Resolved||Daimona||T191430 Re-enable profiling for stashed edits|
|Resolved||Daimona||T191039 Re-enable filter profiling on every wiki|
|Resolved||MusikAnimal||T177017 Re-enable per-filter profiling on wikis where it was disabled|
|Resolved||TBolliger||T177641 Enable AbuseFilter per-filter profiling on Portuguese Wikipedia & monitor if there is a performance impact|
- Mentioned In
- T179323: Enable AbuseFilter per-filter profiling on English Wikipedia & monitor if there is a performance impact
T177760: Enable AbuseFilter profiler for es.wikiquote
T177017: Re-enable per-filter profiling on wikis where it was disabled
- Mentioned Here
- T179604: Move AbuseFilter slow filters data from Logstash to per-filter profiling
T179323: Enable AbuseFilter per-filter profiling on English Wikipedia & monitor if there is a performance impact
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.
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.
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.