Last modified: 2013-04-08 11:02:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 27877 - Parser tests generate too many DB queries
Parser tests generate too many DB queries
Product: MediaWiki
Classification: Unclassified
Unit tests (Other open bugs)
All All
: Normal blocker (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: code_quality
  Show dependency treegraph
Reported: 2011-03-05 20:29 UTC by Max Semenik
Modified: 2013-04-08 11:02 UTC (History)
5 users (show)

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


Description Max Semenik 2011-03-05 20:29:18 UTC
Currently running for 1.5 hours on Tesla and no sign of an end. Tests THAT slow to run aren't going to be used by developers.

The culprit seems to be recreation of every table for every test. Tried replacing drops with truncates, doesn't seem to improve anything radically.
Comment 1 Antoine "hashar" Musso (WMF) 2011-03-07 17:31:43 UTC
rephrased to 
"Parser tests generate too much DB queries"

Marking as blocker (since it blocks advancement of parser related bugs). I get a few thousands database queries PER test.
Comment 2 Mark A. Hershberger 2011-03-08 16:12:59 UTC
Comment 3 Brion Vibber 2011-05-10 23:26:47 UTC
The parser tests have always retained data between individual test segments -- this is needed for instance to create a page, then refer to that same page. Dropping & recreating tables between individual test segments would cause tests relying on data created earlier in the run to fail, in addition to creating a huge amount of additional slow stuff.

Is this some sort of SQLite-specific setup code for parserTests? Or maybe this is in the second copy of the parser tests that's been stashed into the phpunit directory? Does it behave differently from the main parser tests?
Comment 4 Chad H. 2011-05-10 23:28:35 UTC
(In reply to comment #3)
> Or maybe this
> is in the second copy of the parser tests that's been stashed into the phpunit
> directory? Does it behave differently from the main parser tests?

This. It creates a new test for each parser test, and thus goes through the setUp(), tearDown() for each and every parser test.
Comment 5 Brion Vibber 2011-05-10 23:29:10 UTC
So.... that doesn't seem wise. It'll just break a lot of the test cases and be super slow for no reason, right?
Comment 6 Brion Vibber 2011-05-10 23:30:21 UTC
(note that the design of parser tests is to setup/teardown *MediaWiki program state* for each case while retaining *MediaWiki database state* throughout the entire run)
Comment 7 Antoine "hashar" Musso (WMF) 2011-05-11 03:18:34 UTC
tagging 'bugsmash' to get it looked at during the Berlin Hackaton 2011 (this week).
Comment 8 Jure Kajzer 2011-05-14 08:39:12 UTC
I think this was the topic on IRC a while ago, but i think at that time i was told this setup/tear-down procedure on each step was intended to provide consistent state for each step.

So to avoid too much complication i'd suggest to create the "testing state" tables only on first call (i.e.: if tables don't exist) and leave them there after the completion of a test. If tables exist just truncate tables (delete some of them as you wan't to retain initial state like user 1, interwiki, page and user 0 for some DBbs). Finally the tables should be left there after the parsertest finish completely as people doing these test usually 1)don't do it on production servers 2)do it multiple times in a row if dealing with a bug. I think it would be better to just add a parameter to parserTests main class to just clean up testing stuff.

Parser test will usually not create that much data, so this procedure should be faster and easier on the server resources.

Dunno ... thoughts?
Comment 9 Chad H. 2011-05-25 23:00:17 UTC
I fixed this yesterday in r88755.

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