Optimising pipeline concurrency
Optimize pipeline concurrency for performance and cost
Parallel jobs are the unit
Microsoft-hosted capacity is purchased as parallel jobs — concurrency slots. One slot runs one job at a time; a second concurrent job needs a second slot regardless of how long either runs.
That means the questions to ask are:
- How many jobs do we want running at once at peak?
- What is the cost of the queue when we exceed that?
Where concurrency is consumed
Every job consumes a slot: matrix legs, parallel test slices, and the jobs of other pipelines in the organisation. A matrix of eight legs with no throttle will take eight slots if they are free — starving everything else.
strategy:
matrix: { ... } # eight legs
maxParallel: 3 # but only three at a timemaxParallel is how a single pipeline stays a good citizen. Remember it is only valid with matrix, and that parallel and matrix are mutually exclusive.
Self-hosted changes the shape
Self-hosted agents each provide capacity you control. Scaling out is an infrastructure decision rather than a licence purchase — which is what VM Scale Set agents and Managed DevOps Pools exist to automate.
The trade-off to state
More concurrency shortens wall-clock time and raises peak cost or capacity requirements. Less concurrency queues work and lengthens feedback. There is no universally right setting; there is a deliberate one.
Primary sources