Wikimedia Platform Engineering/Site performance and architecture
(Redirected from Site performance and architecture)
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
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
editPerformance 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
editWeekly and monthly status updates at Site performance and architecture/status.
Roadmap
editApril-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- HTTPS by default and SPDY.
- Save Timing.
- ↑ http://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/
- ↑ «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/