Improve speed of running tests #1218
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR activates async throttling of integration tests (instead of reducing parallelism in xUnit, which is what we had before). It uses the approach described at xunit/xunit#2003 (comment).
Throttling is needed to avoid PostgreSQL failing because the maximum number of open connections has been reached (100 by default). As an alternative for throttling, I've tried increasing the max connections limit to 1000 and 500, but without much success.
I've experimented with various throttling thresholds and found a good balance at 64, which leaves some room for abandoned connections (when hard-killing tests during development and debugging). Watching the database server with pgAdmin while running tests, I didn't see more than ~50 temporary databases simultaneously. Measurements confirm that setting the threshold higher doesn't provide measurable gain.
In addition, all models in integration tests now use
DeleteBehavior.SetNull
instead ofDeleteBehavior.ClientSetNull
, so that PostgreSQL performs the related deletes on the database server. That's not only more reliable but also more efficient; it shaves off another ~5 seconds.Running all tests on my computer with:
This yields the following results:
Conclusion: this makes running our tests twice as fast locally! The duration of cibuilds varies wildly, so measurements are not very reliable to compare. Also, their VMs have fewer cores, possibly resulting in more context switches.
QUALITY CHECKLIST