Heat

Heat measures what a request genuinely costs your site on your machine, then works out what happens when there are ten thousand of them — which resource runs out first, at how many visitors, and what to do about it.

The shape of it

1. A measurement pass sends a few dozen sequential requests through your own site and records what each one cost: wall time, real CPU time, database time and query count, peak memory, and whether PHP ran at all.
2. Probes read the machine — the FPM pool, the cgroup CPU quota, available memory, the database’s connection limit and its real query parallelism.
3. The capacity model turns those into a ceiling for every finite resource a request touches, and reports the smallest.
4. A load ladder says what happens at 100, 1,000 and 10,000 simultaneous visitors — throughput, latency, and whether the site is comfortable, queueing or falling over.
5. Remediation says what to change, quoting your own numbers — and when the obvious fix is the wrong one.

Two kinds of number, and Heat says which is which

The ceiling is arithmetic

If a request occupies one of m things for D seconds, the system cannot complete more than m/D requests per second. That is operational law: it holds for any arrival pattern, any scheduler, any shape of traffic, and it needs no assumptions whatsoever. Heat computes it for every finite resource and reports the smallest. This is the number to bet on.

The latency is a model

How bad it gets before the ceiling depends on how requests bunch up, and that needs a queueing assumption: M/M/c, solved through Erlang-C. It is an approximation, and it is the right one — a resource with c servers and roughly independent arrivals is precisely what an FPM pool is — but it is an approximation, and Heat says so rather than presenting it in the same voice as the ceiling.

The site is a closed population

N visitors, each of whom pauses, then clicks. This choice matters more than any coefficient in the model.

An open model — “assume 900 requests per second arrive” — has no answer at all past saturation: the queue length goes to infinity and the prediction becomes the word “infinity”, which is both true and useless. Real visitors are a closed population: when the site gets slow they wait, so they click less often, so the arrival rate falls. That feedback is what makes the numbers past the ceiling finite and, more importantly, what makes them match what actually happens — throughput flattens, latency climbs linearly, and the site does not so much explode as grind.

Visitors are not requests

Ten thousand people reading a page for ten seconds each generate about a thousand requests per second, not ten thousand. Nearly every capacity argument that goes wrong goes wrong exactly there, so think time is a first-class input rather than a hidden constant.

What it is not

• Not a load test. A pass is sequential and small on purpose — see The measurement pass for why that produces a better answer, not a weaker one.
• Not a profiler. Xdebug, Blackfire and New Relic tell you which function is slow in one request. Heat tells you how many of those requests the machine can run at once, and which finite resource stops it. They answer different questions and sit happily side by side.
• Not an APM. Heat has no agent and no daemon, adds no runtime dependencies, and does nothing at all unless you ask it to.

Editions

Lite is free: the whole capacity model, the ranked walls, all the remediation, the machine probes and overrides, the measurement pass for visitor and logged-in load, every traffic mix, and the console commands.

Pro adds the load your team puts on the site — concurrent editor saves and the queue work those saves create — plus run history so two projections can be compared.

Lite reports a higher ceiling than Pro on the same machine, because it is modelling less load rather than finding the load cheaper. Every screen says so rather than letting the number stand on its own.