Wikimedia Platform Engineering/Site performance and architecture
(Redirected from Site performance)
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/