Last modified: 2014-05-22 17:49:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T67394, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 65394 - performance testing environment
performance testing environment
Status: NEW
Product: Wikimedia
Classification: Unclassified
Deployment systems (Other open bugs)
wmf-deployment
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: ops
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-16 13:38 UTC by Sumana Harihareswara
Modified: 2014-05-22 17:49 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sumana Harihareswara 2014-05-16 13:38:31 UTC
A very big, long-term suggestion here: a real performance testing cluster.

The beta cluster is currently unsuitable for testing code for many performance problems, because it is all on VMs. It generally won't tell you about cachebusting either, for several of our caching layers.

Several people are working on Vagrant roles that will help developers test in more realistic environments in dev environments, with million-row databases and warm caches. But CPU and other constraints won't be realistic.

So - as one can see in https://www.mediawiki.org/wiki/Performance_profiling_for_Wikimedia_code - right now, many interactions we can only predict roughly until the code hits production.

It is not possible to have a testing cluster that exactly mirrors production. And of course it is the developer's responsibility to know the constraints of the production system and know how her code exercises those systems. And with heterogeneous deployment, it's *possible* to notice some problems while they're only affecting less-trafficed wikis. But some people have expressed interest in creating a more realistic environment to test/predict how efficient code will be when deployed to very-high-traffic wikis, especially with unique configurations.

So: I'm adding this bug report so that others can comment, WONTFIX it, mention what parts of our performance-related environment are currently hardest to test but would be easier to mock up, etc.
Comment 1 Antoine "hashar" Musso (WMF) 2014-05-16 18:07:03 UTC
CCing Aaron and Ori which are the performance engineers.  I know that at least Ori raised the subject previously in previous bug report.

Maybe we can investigate that after HHVM migration which takes a good share of our productivity this quarter and probably the next as well.
Comment 3 Daniel Zahn 2014-05-22 17:41:36 UTC
does it make sense to bring this up in the "scrum of scrums"?
Comment 4 Greg Grossmeier 2014-05-22 17:49:02 UTC
(In reply to Daniel Zahn from comment #3)
> does it make sense to bring this up in the "scrum of scrums"?

We can, but I think a larger conversation needs to happen between Platform/RelEng/Ops re support/team capacity. It won't be on our (RelEng's) todo list for this quarter, at least.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links