Page MenuHomePhabricator

Performance review of MediaWiki on Kubernetes for Test2Wiki
Closed, DuplicatePublic

Description

Description

Release Engineering and ServiceOps plan to move some portion of production MediaWiki to use Kubernetes. The current option we've discussed is Test2Wiki as:

  1. In discussion with QTE, that wouldn't interfere with manual testing
  2. It would give the Kubernetes cluster real production traffic

This move may have unknown performance implications. And there are multiple performance aspects to consider. Filing this task to facilitate discussion about how best to handle performance testing during this transition process.

Preview environment

Performance can try the Kubernetes environment currently using the WikimediaDebug extension.

Which code to review

The environment and runtime are changing, which involves puppet changes and packaging/deployment changes.

Performance assessment

Please initiate the performance assessment by answering the below:

  • What work has been done to ensure the best possible performance of the feature?
    • Shellbox to ensure performant (and functioning) file uploads
    • Work in MediaWiki/config to load yaml to ensure speedy deployment of configuration changes
  • What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance?
    • Unknown
  • Are there potential optimisations that haven't been performed yet?
    • Unknown
  • Please list which performance measurements are in place for the feature and/or what you've measured ad-hoc so far. If you are unsure what to measure, ask the Performance Team for advice: performance-team@wikimedia.org.

Event Timeline

The mw-on-k8s project has troughout involved close collaboration between SRE/ServiceOps and Performance Team (mainly Aaron and myself).

This work is largely captured by T283056, where the work included functional concerns in terms of what MediaWiki needs as a platform, and benchmarking strategies, identifying important URL routes to benchmark, and end-to-end testing of internal services. Last I checked in on this (which was about six months ago) there were still some benchmarks where we're not yet performing as well, but this is known and I assume has been or is being worked on by SRE as part of tuning php-fpm and balancing pod resourcing.

As such, we do not expect to separately do a performance review as such. We have confidence in the metrics SRE and Perf have in place to monitor this on an on-going basis.

The current option we've discussed is Test2Wiki.

This was discussed elsewhere (no task ref at hand) as part of the mw-on-k8s rollout plan. We have no concerns or preferences for where the rollout begins. Testwiki sounds good!

puppet changes and packaging/deployment changes.

This seems outside the scope of functionality that we typically provide performance review on. If there are specific doubts in the mw-k8s charts and server configuration where you'd like someone in our team to help review something with our "MW core maintainer" hat on, do reach out. Happy to help.

As far as practices and efficiencies go for the individual moving components internally, I defer to ServiceOps to plan and handle that responsibility, and I have confidence in that.

What work has been done to ensure the best possible performance :

  • Work in MediaWiki/config to load yaml […]

It is my understanding that this is not actually something that has been done, and will not be done as part of the initial k8s rollout. This is a major project unto itself, which we're already involved with in collab with PET during both planning and execution, where similarly no separate perf review is expected to be needed given the close nature in which that work is done involving us (mainly with Daniel at the moment).