Page MenuHomePhabricator

FY2026-2027 ST6.4 Logged-in user performance (tracking)
Open, Needs TriagePublic

Description

Background

This year's annual plan includes an effort to increase logged-in readership (see DE3.1 on Meta-Wiki). For this to be feasible at a technical level, performance improvements are needed across the stack.

We started planning for this last year (see WE6.5.1 Plan work for logged-in users performance on Meta-Wiki). Between SRE and MwEng teams we arrived on the following. We drafted through various meetings meeting notes (public) and a drafting excercise (private), which I then used as my closing comment on WE6.5.1 in Asana (private):

We've converged on a two-prong approach:

  1. Try to increase MediaWiki backend capacity for logged-in pageviews.
    • Increase effective capacity through reducing non-pageview workloads. Such as by improving CDN caching of MediaWiki API responses (thus freeing up capacity for pageviews).
    • Increase effective capacity through making MediaWiki serve pageviews faster. Such as through improvements to Parsoid, ParserCache, and MediaWiki more broadly (T302623).
    • Implement SLO for backend pageview timing (latency for end-users), and measure available infrastructure capacity (MW-on-k8s) for pageviews. See also Supported logged in users capacity metric (public) by Giuseppe.
  2. Try to serve some logged-in pageviews from the edge.

Scope

This is a tracking task for this year's work under key result ST6.4. For more details, check FY2026-2027#ST6 on Meta-Wiki:

Key Result ST6.4: By the end of Q3, our platform is able to sustain 20% of page views from logged-in users.

Including:

  • ST6.4.1 Implement SLO for backend pageview request latency (user experience)
  • ST6.4.2 Reduce workload from non-pageview requests
  • ST6.4.3 Allow use of ESI for composition based on user ID at the edge
  • ST6.4.4 Implementation of endpoints in MW to provide the ESI fragments

This task is for tracking work within the ST6.4 KR. For tracking work in other projects that impacts this work (e.g. by assuming something about cacheability, see FY26-27 ST6.4 - Logged-in performance .

Related Objects

StatusSubtypeAssignedTask
ResolvedJdlrobson-WMF
OpenNone
OpenNone
OpenKrinkle
OpenNone
OpenNone
OpenNone
OpenNone
OpenMGoncalves-WMF
ResolvedMGoncalves-WMF
OpenNone
ResolvedKrinkle
OpenNone
OpenNone
ResolvedKrinkle
ResolvedMGoncalves-WMF
OpenKrinkle
ResolvedKrinkle
Resolvedsimon04
OpenBUG REPORTNone
OpenNone
ResolvedKrinkle
Openpmiazga
Openpmiazga
OpenNone
OpenNone
OpenNone
Openpmiazga
ResolvedMGoncalves-WMF
ResolvedMGoncalves-WMF
Openpmiazga
Openpmiazga
OpenNone
OpenNone

Event Timeline

Krinkle updated the task description. (Show Details)
Clement_Goubert subscribed.

Triaging to ServiceOps Radar (Pending) in case this is something where we have actual actions to take, if that's not forecast to be the case please move to Radar (Awareness)