Wikimedia Platform Engineering/Site performance and architecture

The Site performance and architecture team (originally Incremental architectural improvements) was a subteam of Wikimedia Platform Engineering from June 2012 to 2015. Its responsibilities are now covered by the Performance Team and MediaWiki Platform Team.

Team

edit
  • Tim Starling (Lead)
  • Ori Livneh
  • Aaron Schulz
  • Antoine Musso
  • Andrew Garrett

Mission

edit

"Various initiatives geared toward improving site responsiveness, decreasing resource consumption, and/or improving site maintainability."

Rationale

edit

Performance is important for user engagement.[1][2]

Many small architectural changes and improvements are being done all of the time without a lot of fanfare. This is a general activity area where we communicate changes made along these lines.

Status

edit

Weekly and monthly status updates at Site performance and architecture/status.

Roadmap

edit

April-June 2013

edit
  • JobQueue improvements
  • Eqiad migration wrapup
    • Migrate fenari to tin.eqiad.wmnet
    • Migration to Ceph - still running sync scripts, possible split-brain issues with memcache
    • Migrate hume to terbium.eqiad.wmnet

October-December 2013

edit
  • New deployment system (replacing scap)
  • Caching improvements
    • bug 46770 - Rewrite jobs-loop.sh in a proper programming language
    • bug 27935 - Redirect to canonical encoding
    • bug 22390 - When a commons image is updated, update the pages that use it
    • bug 17577 - Include version in thumbnail URL
    • bug 5382 - Queue refreshLinks jobs on template deletion
    • bug 48835 - Separate Cache-Control header for proxy and client
  • bug 15583 - Enable importing across all Wikimedia projects
  • bug 47490 - resetUserTokens.php not usable on large wikis

January-December 2014

edit
  • HHVM AKA HipHop
    • Implement Lua extension
    • Develop prodution configuration

2015

edit
 
Save Timing improved by 20-40%
  1. http://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/
  2. «1 second delay can lead to 11% fewer page views and 16% decrease in customer satisfaction» https://danoc.me/blog/chrome-dev-summit-2015-notes/