Looking back: improvements to edit save time

By Gilles Dubuc, Engineering Manager, Wikimedia Performance Team

The WMF’s financial year and its annual plan are coming to an end, and one of the Performance team’s goals this past year was to reduce the amount of time it takes to save an edit on a wiki.

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.

Featured image credit: Leichtathletik WM 2013 Moskau 100 m Vorlauf, Tobi 87, CC BY-SA 3.0