Rework parallel merge trains concurrency
Problem
Customer Problem:
We experience resource thrashing when pipelines start to backup. We'd like to adjust concurrency to lesson this and make the user experience better.
Tech Debt:
The current parallel merge trains concurrency is badly organized as it simply depends on a feature flag to switch small/medium/high concurrency.
We need to implement this in a more robust approach.
Proposal
- Persist the concurrency factor on database.
- Let operators easily re-tune the concurrency per on-going incident.
- This is for SaaS and Self Managed operators. Customers have indicated they want to tune concurrency themselves.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.