Consider defining K6 tests for parallel execution to more closely emulate real usage
GitLab performance testing currently fixes the scaling parameters of the target instance to the maximum and then runs through all tests sequentially.
It could help make the tests more real world if testing of various subsystems could be run simultaneously.
For instance, in the real world git push and pull operations are happening all the time while other performance tested operations are also happening.
This more real world approach would also help with autoscaling testing since the GPT workloads would be a bit closer to what happens on a real instance.
It would also help mitigate any optimizations that result in uneven testing. For instance, for cloud-based testing various parts of the cloud may optimize traffic to stay in the same AZ - so an AZ based testing node could over drive the AZ specific end points.
This may be as simple as breaking up the tests into categories that can be done by one node or have multiple nodes that can select specific test subsets.
Human kick off of multiple test nodes would be acceptable for an MVC - and maybe permanently.