Page MenuHomePhabricator

[SPIKE] Determine short-term path forward to alleviate strain on parser cache
Closed, ResolvedPublic

Description

This task involves the work and thinking involved with deciding on a short-term [i] path forward for lowering the risk of a parser cache failure by changing how DiscussionTools depends on it.

T267404 and 14-April meeting notes offer context about why an intermediate solution is necessary.

Requirements

  • Volunteers are able to access and use any and all Talk pages project features in whatever configuration they would like.
    • E.g. people should be able to have the Reply Tool turned off while having topic subscriptions turned on.
  • People are able to load talk pages and Talk pages project features with the same speed they are used to
  • Editing Team can monitor performance to verify it is acceptable
  • Any intermediate solution aligns with longer-term plans

Approaches

Approach #1 (T279864): Editing Team removes the cache split (always add reply links), toggle CSS in output page

  • Considerartions
    • Tiny bit worse performance for users who don’t use DiscussionTools, since on a cache miss they will have to wait for the result of our parser which they won’t use
    • Slightly riskier in case of bugs in DiscussionTools, especially with topic subscription feature coming, which could now affect users who don’t use DiscussionTools
    • Less easy to switch on and off: If we change our mind and move away from this, we’d need to either clear the entire parser cache or leave mitigation code around for 30 days after the switch. (But we’ll have the mitigation code already written because it’s necessary for the people without DT enabled anyway.)
    • Aligns with Editing Team's longer term plans

Approach #2: Editing Team uses output page hook to modify HTML

  • Considerations
    • No dependence on Parser Cache
    • Worse performance on every page load, only for users who do use DiscussionTools
    • Easy to switch on and off

Approach #3: Operations team reduces parser cache expiry time (currently 30 days)

  • Considerations
    • Depends on SRE approving this approach.

Open questions

  • 1. Which of the three approaches above is the best choice from a performance perspective?
    • We decided to move forward with "Approach #1 (T279864)"
  • 2. What – if any – other additional considerations need to be added to the ===Approaches section above?

Done

  • An approach to pursue in the short-term is decided upon
  • All ===Open questions are answered

i. As noted in T267404#6999378, there are other longer-term solutions being discussed.

Event Timeline

ppelberg renamed this task from [SPIKE] Determine path forward to alleviate strain on parser cache to [SPIKE] Determine short-term path forward to alleviate strain on parser cache.Apr 15 2021, 12:06 AM
ppelberg claimed this task.
ppelberg updated the task description. (Show Details)

We've implemented Approach #1 in T280295.

The broader work being done to reduce the parser cache utilization is being tracked in T280599 and its sub-tickets.