Hello, This is the first monthly report from the Wikimedia Performance Team. The purpose of these reports is to showcase our work, track our progress, and spark conversation.
## Who we are ## As the Wikimedia Foundation’s Performance Team, we want to create value for readers and editors by making it possible to retrieve and render content at the speed of thought, from anywhere in the world, on the broadest range of devices and connection profiles. We are five engineers: Aaron Schulz, Gilles Dubuc, Peter Hedenskog, Timo Tijhof, and me. Each of us was born in a different country and has a different mother tongue. We work out of San Francisco, London, Stockholm, and Montpellier. ## What we are working on ## * Availability. Although Wikimedia Foundation currently operates six data centers, MediaWiki is only running on one (in Ashburn, Virginia). If you are an editor in Jakarta, Indonesia, content has to travel over 15,000 kilometers to get from our servers to you (or vice versa). To run MediaWiki concurrently from multiple places across the globe, our code needs to be more resilient to failure modes that can occur when different subsystems are geographically remote from one another. https://phabricator.wikimedia.org/T88445 * Performance testing infrastructure. WebPageTest provides a stable reference for a set of browsers, devices, and connection types from different points in the world. It collects very detailed telemetry that we use to find regressions and pinpoint where problems are coming from. This is addition to the more basic Navigation Timing metrics we gather from real users in production. https://phabricator.wikimedia.org/T109666 * Media stack. We're currently working on overhauling our thumbnail infrastructure to achieve multiple goals. Improving future-proof maintainability by taking thumbnail code out of MediaWiki-Core and using a service instead to perform thumbnail operations. Saving on expensive storage by no longer storing multiple copies of all thumbnails on disk forever. Enabling far-future expires for images, to greatly improve their client cacheability. And finally switching to the best performing underlying software to generate thumbnails faster. https://phabricator.wikimedia.org/T111718 * ResourceLoader. ResourceLoader is the MediaWiki subsystem that is responsible for loading JavaScript and CSS. Whereas much of MediaWiki's code executes only sparingly (in reaction to editors modifying content) ResourceLoader code runs over half a billion times a day on hundreds of millions of devices. Its contribution to how users experience our sites is very large. Our current focus is on improving ResourceLoader's cache efficiency by packaging and delivering JavaScript and CSS code in a way that allows it to be reused across page views without needing to be repeatedly downloaded. https://phabricator.wikimedia.org/T102578 ## How are we doing? ## In future reports, we will spend less time on introductions and more time reporting on how particular performance metrics have trended since the previous report and why. In the meantime, we invite you to check out our dashboards: * https://performance.wikimedia.org/ * https://grafana.wikimedia.org/dashboard/db/navigation-timing * https://grafana.wikimedia.org/dashboard/db/time-to-first-byte * https://grafana.wikimedia.org/dashboard/db/job-queue-health ## Feedback? ## Please let us know what you think about these reports and whether we have picked the right lists to send it to. (We're going to make sure this information is available on mediawiki.org too.) Until next time, Aaron, Gilles, Peter, Timo & Ori _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
