Skip to main content
An Aspect Enterprise deployment has two kinds of capacity, both counted in vCPUs: CI runners, and remote execution workers. Each is a ceiling you configure, and you can raise or lower it at any time. Below the ceiling, runner groups and worker pools scale between bounds you set, down to zero when idle.

​
Start from your current CI

Two numbers describe what your CI uses today:
  • Peak concurrent jobs: the most CI jobs running at once on a busy day.
  • Runner size: the vCPUs of the machines those jobs run on.
With more than one runner size, add up each size’s product. Count only the jobs that run Bazel. Jobs that don’t, such as a Docker build outside Bazel, keep whatever machines they use today. Without remote execution, peak CI vCPUs is your CI runner estimate.

​
CI runners

4 vCPUs is the practical minimum for a runner that runs Bazel. Without remote execution, a job’s actions all run on its runner, so the runner’s vCPUs set how many run in parallel. A larger runner builds a job faster, up to the parallelism the build has. With remote execution, the runner runs Bazel and sends actions to the fleet, so smaller runners can keep hundreds or thousands of actions in flight. That lowers the CI runner capacity you need:
  • Smaller runners. A job no longer needs a large machine to build quickly.
  • Fewer runners at peak. Faster jobs finish sooner, so fewer run at the same time.

​
Remote execution

Each worker in a pool runs a number of action slots, and the vCPUs per slot are yours to set: A deployment can have several pools, one per platform or machine shape, each sized on its own. A pool’s ceiling is its maximum workers times the vCPUs per worker. To estimate what that ceiling should be:
Three things set peak actions in flight:
  • Concurrent builds. Peak actions in flight is the sum across every build running at once, from CI and from developers.
  • Bazel’s --jobs, the most actions one build keeps in flight. Builds on remote execution raise it far above the runner’s core count; Parallelize remote execution uses 32 times the core count as a starting point.
  • The build’s own width, how many actions are ready to run at once. Only cache misses reach the fleet, so a warm cache keeps most builds far below --jobs. A full uncached build is the widest you’ll see.
Without a Bazel build on remote execution to measure yet, today’s CI is a rough floor: the vCPUs that run actions on your runners now are about the action throughput the fleet has to match. Expect queueing at peak if the fleet sits at that floor, and leave headroom if the build relies on persistent workers, such as javac or tsc workers, which usually run locally and cost more CPU per action when executed remotely. Developers on the external endpoint add load too: to CI’s fleet when the endpoint shares it, or as a separate fleet of their own.

​
A worked example

A team runs 40 Bazel jobs at peak on 16 vCPU runners, 640 vCPUs in all. At that floor, a job running alone can use far more than its old 16 vCPUs, and 40 jobs at once queue for the fleet. The trial measures where your peak sits, and adjusts both numbers: peak concurrent jobs falls as jobs get faster, and the fleet’s ceiling goes up or down with how wide your builds run.

​
Bring to the first call

  • Peak concurrent Bazel jobs, and the runner sizes they run on
  • Your CI provider
  • The platforms you build for: Linux x86 or Arm, GPU, macOS
  • Pull request wall time today, p50 and p90
  • Whether developers will use remote execution from their laptops
  • Hosted by Aspect, or self-hosted in AWS or GCP
A trial measures your build on the deployment. Its peak usage and critical path show where to add or take away capacity, then and as your build grows.