Problem/Motivation
Core performance test are (somewhat ironically) some of the slowest functional javascript tests in core.
This is because they rely on creating somewhat realistic scenarios (standard and umami profile), and on the chrome performance log which has a lot of quirks. To avoid this, most of the tests only add performance assertions and opentelemetry logging for a single page/operation.
However, since PerformanceTestBase was added, we've fixed a lot of weird performance log timing issues and other race conditions, so it might be OK to try to consolidate things down to fewer methods or one per test class, with more requests/assertions in each.
Doing this for StandardPerformanceTest first since it's the smaller compared to Umami
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3463288
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
catchLocal ddev timings. Down from nearly 9 minutes to 1m43. On gitlab it currently finishes after about 4m10s so would expect it to finish in somewhere around 1 minute give or take.
Before:
After:
Comment #4
catchComment #5
smustgrave commentedOh nice, I like tests like this that call the functions. Wonder if we could make that more standard?
Change here looks good though, no loss of coverage.
Comment #8
longwaveMakes sense to me, as long as it doesn't affect the timings why reinstall over and over. Backported down to 10.3.x as a test-only change.
Committed and pushed 24b7c3ffa3 to 11.x and 64e80c8d84 to 11.0.x and 12448d24bc to 10.4.x and 816ac01be9 to 10.3.x. Thanks!
Comment #11
smustgrave commentedCan I ask a good rule of thumb on when this would be preferred
Comment #12
longwaveI don't think there is one, it's kinda case by case - it's suitable when the individual tests don't do much work but also we must ensure that combining them doesn't cause side effects where data from an earlier test leaks into a later one.
Comment #13
catchAn example of it not working is in #3463351: Consolidate Umami performance tests which I am currrently struggling with. Passes locally but fails with what looks like a race condition in the chrome driver on gitlab.
However if it's a functional or functional javascript test, and we don't need to make big changes for the test to work, then it makes everything run a lot faster.
Comment #15
wim leers#2: 🤯 Wow, now that is an epic speed-up! 😄