Cache test starting point to increase testing speed by about 25%
With D7 sites, I use the module Simpletest turbo which caches the result of tests' setUp() function so the starting point of a test can be carried over from one test to another without going through all the steps to install Drupal.
To see if such an approach could benefit Drupal 8, I started by installing Drupal 8.0-alpha12 with a MySQL database, and running the four first tests in the Node group, from the GUI.
On my computer (Mac OS X with MAMP), these tests were performed in 1 minute 9 seconds during the first run. (I ran the same tests twice, and both times the time taken was the same.) The time it takes to run a test can be broken down as:
- 69 seconds total
- 24 seconds (35%) for
install_drupal(4 * 6 seconds).
If we could apply the principle of Simpletest turbo, I think it not unreasonable to shave 2/3 off the 24 seconds it takes to install Drupal by reusing a previous installation database rather than reinstalling everything. If this can be achieved, the four tests in our sample would take 69-(24*.66), or 53 seconds. By extrapolating, we could make the testbot 25% more efficient overall.
Comments
Comment #1
alberto56 commentedComment #2
alberto56 commentedThis patch is a proof of concept and has only been tried with a MySQL database on the GUI (not the commande line), but I managed to get a 14.7% performance increase using Simpletest.
To use the patch:
Note: this is only a proof of concept. The following could be done:
Comment #3
alberto56 commentedHere is the screenshot
Comment #5
alberto56 commentedOK, maybe 25% is exaggerated. 15% is still respectable. Updating title.
Comment #6
alberto56 commentedIn an attempt to get some metrics on the command line, I ran the following command on my computer with PHP 5.5 and a MySQL database.
The idea was to run a small subset of available tests to see the speed difference with this approach.
Note that the patch in #2 no longer applies to 8.x, so I modified it slightly and applied it. I also am now clearing tables before starting the command line operation.
Without the patch the test ran in 2 min 6 sec
With the enclosed patch the test ran in 1 min 23 sec
Which is 34.13% faster according to my calculations. It should be noted that the more tests are run, the bigger the speed increase will be (in theory anyway). So perhaps the 15% in the title is a bit conservative.
To have a better idea of the actual speed increase, I am including two patches
here, one which changes nothing in Drupal, and the other which implements the solution discussed herein. The idea then is to compare the time it takes the testbot to test each patch.
Here is my output:
Comment #7
alberto56 commentedComment #11
alberto56 commentedSeems by dummy patch is not applying. Here is a new attempt. Please do not use this patch; use the one at #6, above. The one here is simply here to have a baseline on how much time the testbot normally takes to run a test (to be taken with a grain of salt given the various factors affecting performance).
Comment #12
alberto56 commentedComment #14
alberto56 commentedhttps://qa.drupal.org/pifr/test/841008 ran in 33 min 35 sec
https://qa.drupal.org/pifr/test/841018 ran in 33 min 42 sec
A bit anticlimactic. But hope is not lost.
Comment #15
alberto56 commentedThe reason why the testbot doesn't show a speed increase is because the patch does not increase speed when concurrency is used:
Each child concurrently builds the environment so none can use the cached environment, it seems.
Comment #18
droplet commentedI think the basic concept still valuable. Loading a SQL dump are so common in PHPUnit tests. There's maybe some concerns blocking this trick in d.org testbots. But I think at least we could provide an option for the developer to switch it on / off and capture particular DB snapshot.
Running an empty JavascriptTestBase test on Windows on a high-end PC. It took 47s.
A simple issue easily took an hour on little debugging: #2782915: Standardize the behavior of links when Outside In editing mode is enabled
As a developer, we understand what's going to test. A standard Drupal Installation bootstrap doesn't that important in most Patch Development & Re-testing on failing tests.
I wonder how possible to raise this issue to Critical Priority? Minimize Tests waiting time, we could focus more on patching.
** Although I thought it's not so right, I marked it as "Needs Review". A comment in this issue told me I can do it (, let me try if I could): #2747641: Add status "Needs Feedback" to issues
Comment #19
droplet commentedJust see another issue trying to implement DB caching, pretty good movement tho: #2747075: [meta] Improve WebTestCase / BrowserTestBase performance by 50%