By Gilles Dubuc, Engineering Manager, Wikimedia Performance Team
This set of metrics, which we call Save Timing, is publicly tracked on Grafana. It’s recorded for all Wikimedia wikis. It’s a critical performance pain point for editors, as edits on large wiki pages can sometimes take seconds to save.
We distinguish the amount of time the backend takes to process the edit, from the amount of time the end-user actually experiences to save the edit (collected client-side). We’ll focus on the latter, as this is what people really experience. Backend traffic can come from bots, jobs, etc. where long execution times atypical of human edits affect the metrics.
Let’s look at the evolution of frontend save timing since the beginning of the financial year, on July 1st 2016.
The 99th percentile, which represents the slowest editors experience dropped significantly:
Going from 22.4 to 16.82 seconds (weekly average), a 25% improvement.
So did the median:
Going from 953 to 813 milliseconds (weekly average), a 15% improvement.
Aaron Schulz deserves most of the credit for this tremendous performance improvement that editors experience every day. Performance is a never-ending goal and we hope to achieve even better save timing in the future thanks to our continued work in this area.
About this post
This post was originally published on the Wikimedia Performance Team Phame blog.