System requirements: how much machine for how much load

This page tells you how much CPU, memory and disk to set aside before you install Spitfire on your own servers: on one machine with Docker, on Kubernetes and when the load is spread over other machines. The figures are given by the number of virtual users (VUs) and requests per second you expect.

Software

• One machine: Linux (amd64 or arm64) or macOS with Docker Engine or Docker Desktop and Docker Compose v2. On Windows 10/11 and Windows Server, Docker Desktop (Linux containers) and PowerShell.
• Kubernetes: kubectl and the right to install into a namespace; a StorageClass for the persistent disk (unless Postgres lives outside). There is a Helm chart too.
• Remote runner server: Docker; or systemd on Linux without Docker, a Windows service on Windows without Docker.
• Database: the Postgres 16 that comes with the installation, or your own Postgres.
• Ports: 8470 for the web UI and API; 8471 (TLS) for runners on other machines. No inbound port on the runner machines.

First, work out your own load

VUs and requests per second relate like this: requests/s ≈ VUs ÷ (response time + think time). 1,000 VUs against a system that answers in 200 ms with 1 second of think time make about 830 requests per second; without think time, 5,000. What loads a runner is mostly requests per second (CPU), while the VU count decides the memory. In the tables below, go by whichever of the two fills up first.

One machine (Docker)

The install command starts Postgres, the controller and the runners on the same machine (--runners N, 2 by default). The machine size is the three together:

Choose half as many runners as vCPUs (--runners 4 on 8 vCPUs). Above 10,000 VUs add runners on other machines rather than growing one machine; the network card is often the limit.

Kubernetes

On Kubernetes the controller and Postgres take a small, fixed share; the part that grows is the runner pods. The Helm chart's default runner pod uses at most 2 vCPU / 1 GiB and carries about 10,000 requests/s or 3,000 VUs. Pick the pod count by the larger of requests/s ÷ 10,000 and VUs ÷ 3,000:

• The node count is the sum of the runner pods' CPU limits plus ~2 vCPU for the controller and Postgres. Give the runners their own node pool; load generated on the same nodes as the application you measure skews the result.
• With on-demand runners (--on-demand-runners N) the runner pods take room only during a run; with a cluster autoscaler the nodes come up only then too.
• For more VUs per pod, give it more memory (Helm: runner.resources.limits.memory; for on-demand runners SPITFIRE_ONDEMAND_MEMORY and SPITFIRE_ONDEMAND_VUS_PER_RUNNER).

Per component

If you put the controller, the database and the runners on separate machines:

• Disk: Postgres keeps per-second results for 7 days by default; summaries stay. 50 GB is comfortable for a team running a few hours of tests a day; if you lengthen retention, grow the disk too. SSD recommended.
• File descriptors: every VU holds at least one socket. The installation gives runner containers 65,536; on runners without Docker raise ulimit -n to at least that too.
• Browser steps (Web Vitals) open a real Chromium: ~350 MB of memory and ~20% of a core per browser VU. They run on separate runners with the -browser image.

Where these figures come from

In Spitfire 0.56.1, a runner limited to one core loading a target that returns small responses over HTTP keep-alive produced 34,000-40,000 requests per second; each waiting VU with its open connection held ~70 KB of memory (711 MB at 10,000 VUs). That was measured on a fast laptop core against a target on the same machine. The planning figures are deliberately far below it (5,000 requests/s per vCPU, 3,000 VUs per GB): they leave room for HTTPS, JSON responses of a few KB, checks and extraction, an ordinary cloud vCPU and network latency.

The best figure for your own test is your own measurement: run it at a tenth of the expected load and watch the CPU column on the Runners page. When a runner gets close to its CPU limit, Spitfire warns that "results may be skewed"; add runners then. Installation details are in the installation guide, distributed load on Kubernetes in the Kubernetes guide.

Frequently asked