(NOTE) Please feel free to edit and to link each item to the appropriate task, creating one if necessary.
* Weekly performance reports with KPIs (Ori)
* Multi-DC MediaWiki
** Swift repl. solution
** 100% readiness of PHP code
* Solve all (5-6) thumbnailing problems on a VM.
** Scaling in a service outside MediaWiki.
** New hash-based URL scheme
** Article purging on image update (not a goal, but side effect of point below probably?) it's a prerequisite for the following point
** Far-future expires for thumbnails.
** Hash-based purging.
** To swift or not to swit, for thumbnail storage.;
probably only for reference-size thumbnail (incl.each page in multipage format) and unusual formats that thumbor doesn't support yet
Hm.. so we'd the other ones in thumbor? If not, the storage (e.g. varnish) can be for both mw-scaled and thumbor-scaled thumbnails.
Yes, varnish would cache both JPGs/PNGs generated by thumbor and the rest still coming form mediawiki. Thumbor will have its own file-based cache in lieu of swift for "safety" in case of varnish disaster.
Ah, so thumbor would also store each thumbnail it generates.
Yes, with an expiry, unlike swift
(deterministic url-hash based host selection, ala varnish-backend?)
not sure how that works for varnish backends, but yes we can be smart about how we pick thumbor servers. especially since we can have thumbor in the PoPs.
FYI, out-of-the-box thumbor does JPG and PNG well, which is 91% of files on Commons
Bonus: Thumbor supports webp rendering. We could automatically serve webp to browsers that support it. Might have community implications, though ("breaking" right-click + save)
* ~~Slow parse log community tool + page performance debugging tool~~
* Reading team performance process
** Performance budget + synthetic testing (shared goal with Reading)
** WebPageTest infrastructure
* Programmatic pool / depool of application servers (blocker for RepoAuth) (Ori)
* Refine and stabilize ResourceLoader (Timo)
* ~~MySQL monitoring - Anemometer (forwarding slow query log to central aggregator and deploying UI tool)~~
** Use DBPerformance log instead (beef it up if needed, already logs slow reads/writes/transactions)
*** Kibana has various features we can utilise to provide beter insight into the data and trends.
** Questionable value given existing Kibana UI for queries from MediaWiki