We should log cases where abusefilter filters take an extremely long time to run so that we can identify filters that may need to be optimized or that might require some improvements to the underlying code.
|Resolved||None||T166802 Epic ⚡️ AbuseFilter performance management improvements|
|Resolved||dmaza||T161059 Measure AbuseFilter runtime|
|Resolved||dmaza||T174205 Log cases where abusefilter filters take over a certain amount of time to run|
|Resolved||dmaza||T179039 Change threshold for slow AbuseFilter logging from 500 ms to 800 ms|
- Mentioned In
- T179604: Move AbuseFilter slow filters data from Logstash to per-filter profiling
T179039: Change threshold for slow AbuseFilter logging from 500 ms to 800 ms
T177651: On-wiki consultation about surfacing AbuseFilter perf. measurements to Edit filter managers
T176895: Surface slow filters and total condition count directly on Special:AbuseFilter
T177017: Re-enable per-filter profiling on wikis where it was disabled
T174204: Build graph/dashboard for AbuseFilter profiling data
- Should I remove the old profiling logic? I remember conversations about it saying that it is useless 'cause it adds about ~1 sec to each edit. It is a lot of code and it is cluttering the extension. I see no reason to keep it.
- I propose to use the same flag $wgAbuseFilterRuntimeProfile to enable/disable this functionality, like we use for the data pushed to statsd. It is all runtime profiling in the end.
- I'm thinking on logging wikiId, filterId, totalRuntime, totalConditions to logstash. Do you agree?
If someone else needs to be tagged in this ticket, please tag them.
Correct — the profiling is still enabled on other wikis: https://es.wikipedia.org/wiki/Especial:FiltroAntiAbusos/4
De las últimas acciones, este filtro ha coincidido con 0 (0,00%). En promedio, su tiempo de ejecución es de 0,27 ms, y consume 4 condiciones del límite de condiciones.
Yup, other wikis are using the profiling, but I was told it's not so accurate. It does give a general idea of which filters are taking a long time compared to other filters, so still of some use I suppose. It'd be nice if we had better profiling that didn't slow down editing =P Then maybe enwiki could get it back! We miss it :'(
That being said, not sure if your opinion on whether to use $wgAbuseFilterRuntimeProfile changes. For now I'd probably leave things as-is, and one day we can revisit improving per-filter profiling.