Spitfire
Version comparisonat the same timePreview

Is the new release slower? Find out before it goes live.

Run the same test, with the same load, at the same time, against the environment running the old release and the one running the new release. Every runner splits its load evenly between the two, so network and timing differences do not skew the result. At the end Spitfire shows the difference step by step and says it plainly: better, no difference, or worse.

Version comparison is in preview: it works, and details may change.

spitfire.local/comparisons/…
Spitfire: a finished comparison run. Verdict: worse; checkout p95 from 219 ms to 268 ms (+22%), search from 150 ms to 130 ms (−13%). Below, both releases' request rate and p95 charts.
A finished comparison run: the verdict card, the largest differences and both releases' charts. Real screenshot.

When to use it

Before a release

The new release runs next to the old one under the same load before it goes live.

An infrastructure change

A new database version or a new server type: the old and the new infrastructure meet the same test.

A library or framework upgrade

See where performance goes when the framework, the ORM or the runtime version changes.

A configuration change

Connection pool size or a cache setting: measure the change instead of guessing.

How it works

  1. STEP 1

    Pick the environments

    From the test's Environments tab pick the one running the old release as A and the one running the new release as B, and write the version labels.

  2. STEP 2

    One run, both at once

    The same test runs against both environments at the same time with the same load; the live screen shows both arms side by side.

  3. STEP 3

    Verdict

    At the end, a step-by-step difference table and the verdict: better, no difference, or worse.

spitfire.local/comparisons/…
Spitfire: the comparison screen while the run is going; the v2.3 · test and v2.4 · dev series fill side by side on the request rate and p95 charts.
While it runs: both releases' series fill side by side on every chart. Real screenshot.
spitfire.local/comparisons/…
Spitfire: the per-step difference table (p50, p95, p99, errors, requests/s and the step verdict) and a separate comparison for every step of the load.
When it ends: the per-step difference table and a separate comparison for every step of the load. Real screenshot.

Like for like

A comparison means something only when both sides are measured under the same conditions.

Evenly split load

Every runner splits its virtual users evenly between the two arms, so a slowdown on the runner (CPU, network, GC) hits both alike. Load steps change on both arms at the same moment, and the location split is the same.

How to read the result

Which plans

PlanVersion comparison
Free1 a month
Project pass (30 days)✓
Quarter (90 days)✓
Growth yearly✓
Enterprise yearly✓

In a comparison run the virtual user, requests/s and runner limits apply to both arms together: each arm uses half.

Frequently asked

How do I know whether the new release is slower than the old one?
With a comparison run. Pick the environment running the old release as A and the one running the new release as B. Spitfire runs the same test against both at the same time, and every runner splits its load evenly between them. The result shows the difference and the verdict for every step: better, no difference, or worse.
Why not run twice and compare the two runs?
Between two runs at different times the network, the caches and the load on shared infrastructure can change. Running both at once spreads those outside effects evenly over the two sides; what is left is the difference the release makes.