Wikimedia Platform Engineering/Site performance and architecture

From mediawiki.org

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/