Repository navigation
Reset and restore the test database without starting client processes #386
Description
The framework runs its own database bookkeeping through a new mysql client process each time. Per scenario that means a connection test and a DROP DATABASE before it starts. Scenarios that install WordPress add a CREATE DATABASE and an import of the cached install dump. Each client process costs about 25 ms before it does any work, and the import costs about 260 ms.
Steps:
- Test the database connection once per suite instead of once per scenario.
- Run the drop and create statements over a single persistent connection from the Behat process.
- Restore the cached install over that same connection.
Locally this brought a trivial query from 28 ms to 0.2 ms, and the import from 258 to 191 ms on a regular database (79 to 15 ms on an in-memory one). The database ends up in the same state as before.
Measuring: take the baseline from #384, then open a draft PR, run the same CI jobs against it and record both results here before we decide.
Activity
schlessera commentedon Oct 30, 2026
Measurement
Measured on GitHub Actions with the full test matrix of
core-commandandcache-command, run onmeasure/*branches of wp-cli/core-command#350 and wp-cli/cache-command#137. All runs use wp-cli-tests at the same base commit (9298472) and differ only in the changes of #402.The metric is the Behat wall time of each job, from the start of the Behat step to its last summary, for the 49 Linux jobs present in all runs. "Total" is the sum over these jobs, "per job" the median of each job's change against the mean of the two baseline runs. Both baselines run the identical code, so their spread is the noise level: about ±1% for
cache-commandand about ±5% forcore-command. All runs executed the same scenarios (about 4,518 forcore-commandand 1,162 forcache-commandacross the Linux jobs).core-commandtotalcore-commandper jobcache-commandtotalcache-commandper jobThe difference is within the noise for
core-commandand at its edge forcache-command(-4.9% in total). Locally, each operation got much cheaper (a connection check from 28 to 0.2 ms, restoring the cached installation from 258 to 191 ms), but on the runners these operations are evidently a small share of a scenario.