Performance measurement and benchmarks #

This page is for engineers who need numbers: to compare servers, to prove a change made nothing slower, or to find where a page spends its time. Exponential ships its own benchmark command, so no external load tool is needed. The reference is Benchmark: exp:benchmark and the step-by-step guide is Benchmarking Exponential.

Contents #

1. The four modes
2. Safe by default
3. Performance checks in CI
4. Finding where the time goes
5. Comparing fairly
6. Reading published numbers

The four modes #

./console exp:benchmark --allow-root-user          # http: the front page, three menu pages, the admin login
./console exp:benchmark kernel --allow-root-user   # the parts of a page, in-process
./console exp:benchmark micro --allow-root-user    # hot paths, no web server, no database
./console exp:bench --help                          # exp:bench is the short name

php bin/php/benchmark.php ... is the same command without the console.

Safe by default #

A benchmark is load. The defaults are polite (100 requests per URL, 4 at a time, GET only), and anything that looks like a load test of somebody else's server (another host, high concurrency, many requests) needs --force. A host the site does not serve is refused unless its URLs are named explicitly. --cold-clear is the one option that writes: it clears the content view cache first; --cold measures past the caches without clearing anything.

Performance checks in CI #

The Performance workflow runs the micro benchmark (PHP 8.5) on a push or pull request that changes PHP, templates, settings/ or the benchmark itself, against tests/benchmark/baseline.json. A probe over the threshold is measured once more and only the second run counts. It is a warning, not a blocking check. Reproduce it with:

php bin/php/benchmark.php micro --baseline=tests/benchmark/baseline.json --all-checks

with OPcache off for the command line (Continuous integration).

Finding where the time goes #

• The debug bar shows page time, SQL count and time, peak memory and templates used, with tabs for timing, SQL, templates and memory (The Exp Debug bar). Turn it on for your own address only.
• The kernel mode of the benchmark splits a page into its parts.
• Velocity has an opcode cache report and a profile (Velocity opcode cache and profile).
• Profiling guidance for application code: Profiling and performance.

Comparing fairly #

• Compare A and B back to back, on the same machine, with the same caches warm or cold.
• Use medians over many requests, not single requests or best cases.
• Change one thing at a time: the engine, a setting or the code.
• Note the PHP version, the engine, the database and which caches were on.
• Judge Velocity's memory by PSS, never RSS.

Reading published numbers #

The README documents figures for the Velocity stack (for example a median per cached page and requests per second on a 12-core machine) and says the methodology and scripts ship with the project. Treat any published number as a measurement on that hardware, with that page and those caches, and repeat it on yours before you plan with it.

Related pages #

• Caching layers for engineers
• Benchmarking a hosted site
• HTTP/2 and cache warming
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.