Amdahl's law: formula, examples and scaling limits

Amdahl’s law says that the speedup from running work in parallel is capped by the part that cannot run in parallel. If a fraction p of the work spreads across n processors, servers or threads, the speedup is S = 1 / ((1 − p) + p/n), and however large n grows it never passes 1 / (1 − p). With 95% of the work parallel, the ceiling is 20 times, even on a thousand machines.

The numbers below are arithmetic, with no test run behind them. The papers cited were checked on 1 November 2026.

What does the law say in simple terms?

A job can finish no faster than its serial part, so extra workers shrink only the rest. Once the parallel part is small next to the serial part, more workers barely change the total time.

Take a 10-second job where 1 second is serial (a lock, a single write) and 9 seconds split evenly, so p = 0.9. Eight workers finish it in 1 + 9/8 = 2.125 seconds (4.71 times faster); sixty-four need about 1.14 seconds. Nothing gets it under 1 second, so 10 is the ceiling.

Where does the law come from?

Gene Amdahl made the argument in 1967, at the AFIPS Spring Joint Computer Conference, in a paper defending the single-processor approach.

We have not read the full text of Validity of the single processor approach to achieving large scale computing capabilities. Mark Hill and Michael Marty’s Amdahl’s Law in the Multicore Era (IEEE Computer, 2008) summarizes it: one fraction infinitely parallelizable with no scheduling overhead, the rest totally sequential, and the speedup described “without presenting an equation”.

What does it mean for load and capacity testing?

Throughput stops growing in step with servers, threads or pods once a shared component handles part of every request one at a time. A load test shows it as a throughput curve that flattens while you keep adding capacity.

Neil Gunther’s 2008 paper, cited below, writes the same law as N / (1 + σ(N − 1)), with σ the serial fraction, and measures scalability as throughput at N divided by throughput at 1. In a web system, the serial part is whatever every request passes through in turn: a lock or a row every request updates, a single database primary taking all writes, a single queue consumer or a rate-limited third-party API.

How do you find the serial part in a load test?

Run the same test at several load levels and watch which resource saturates as throughput flattens. The component at its limit when extra capacity stops paying off is the serial part, or the queue in front of it.

Typical signs: throughput levels off while the app tier has spare CPU, waits grow in one shared place (locks, database connections, queue depth), and response time rises in step with users, which is Little’s law at a ceiling. A run at one constant load cannot show this, so step the load. In LoadFocus, the Ramp Up Steps setting adds virtual users in equal batches, and the Capacity panel groups a finished run by active virtual users and, on paid plans, lists p95, requests per second and error rate per level for single-generator runs. The panel names a capacity level only when the run climbed through at least three levels and the top level was at least double the lowest. It fits no scalability model, so the fit below is yours to do.

What is Gustafson’s law?

It is the counterpoint: if the problem grows with the machine, the serial share stays small and speedup grows almost linearly. Amdahl holds the work fixed; Gustafson holds the run time fixed.

John Gustafson’s 1988 note Reevaluating Amdahl’s law reported speedups of 1016 to 1021 on a 1024-processor hypercube at Sandia, for applications with a serial share of 0.4 to 0.8 percent, and argued that users enlarge the problem to fill the time they have. With s’ as the serial share measured on the parallel run, scaled speedup, a formula the note credits to E. Barsis at Sandia, is N + (1 − N)s’.

At s’ = 0.05 and 64 processors that gives 60.85, against 15.42 for Amdahl, because the two 5% figures come from different machines. In a web system, Gustafson fits when each added server works on its own share of the data; Amdahl fits when every extra user still touches the same shared row.

What does the Universal Scalability Law add?

A second term for coherency, the cost of keeping shared data consistent between workers, which grows with the number of worker pairs. With it, throughput can peak and then fall as you add capacity.

Gunther’s A General Theory of Computational Scalability Based on Rational Functions (arXiv, 2008) states the Universal Scalability Law (USL) as:

C(N) = N / (1 + σ(N - 1) + κN(N - 1))
peak at N* = sqrt((1 - σ) / κ)

σ is contention (serialization or queueing) and κ is coherency (inconsistent copies of data); with κ = 0 it is Amdahl’s formula. Gunther’s worst-case examples include updating database records, and he calls throughput beyond N* “retrograde”. With illustrative values σ = 0.05 and κ = 0.001, the peak sits near 31 workers: relative throughput is 9.03 at 32 and 7.82 at 64, where the σ term alone predicts 15.42.

How do you fit the USL to a load test series?

Measure throughput at several concurrency levels, divide each by the throughput at one user, and fit σ and κ by least squares.

Rearranged, the formula reads N / C − 1 = σ(N − 1) + κN(N − 1), which is linear in σ and κ. The values below are generated from σ = 0.05 and κ = 0.001; put your own requests per second per level in x:

import numpy as np

n = np.array([1, 2, 4, 8, 16, 32])          # virtual users
x = np.array([50, 95, 172, 284, 402, 452])  # req/s per level
c = x / x[0]                                # relative capacity
A = np.column_stack([n - 1, n * (n - 1)])
(s, k), *_ = np.linalg.lstsq(A, n / c - 1, rcond=None)
print(f"sigma={s:.3f} kappa={k:.4f}")
print(f"peak near {np.sqrt((1 - s) / k):.0f} users")

It prints sigma=0.050, kappa=0.0010 and a peak near 31 users. Change only concurrency between levels, and include a one-user level, since every point is divided by it.

Where do these models stop being useful?

They compress a throughput curve into one or two constants, so they cannot name the lock at fault or follow a system that changes under load. Use them to read a measured curve and extend it a short way: a fit on levels far below the knee says little about the peak.

• Constant parameters. A warming cache, an autoscaler or a pool hitting its limit changes σ and κ mid-test.
• Throughput only. p95 and p99 can degrade first: check tail latency too.
• The load generator. If it saturates first, the flat curve is its own.
• Closed tests. Fixed virtual users measure a closed system; real users arrive at their own rate.

FAQ

Can you explain Amdahl’s law in a simple way? A job is only as fast as the part of it that cannot be shared out. If one tenth of the work must run serially, no number of extra workers makes the job more than ten times faster, because that tenth still takes the same time.

What is Gustafson’s law? Gustafson’s law says that when the problem grows with the number of processors, speedup grows almost linearly, as N + (1 − N)s’, with s’ the serial share of the parallel run. John Gustafson published it in 1988 (crediting the formula to his Sandia colleague E. Barsis) as a counterpoint to Amdahl’s fixed-size assumption.

Related reading

• Little’s law in load testing: size and check your tests
• Throughput vs latency: how they interact under load
• Open vs closed workload model: which one should you use?
• Tail latency: what it is and how to measure it
• Queueing theory: what it is and why latency spikes

The technical claims in this article have not been independently reviewed.