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 any information on this page.
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.
- Tim Starling (Lead)
- Ori Livneh
- Aaron Schulz
- Antoine Musso
- Andrew Garrett
"Various initiatives geared toward improving site responsiveness, decreasing resource consumption, and/or improving site maintainability."
Performance is important for user engagement.
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.
Weekly and monthly status updates at Site performance and architecture/status.
- 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
- 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
- HHVM AKA HipHop
- Implement Lua extension
- Develop prodution configuration
- 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/