Benchmark: exp:benchmark #

Diese Seite richtet sich an Websitebetreiber und Entwickler, die wissen möchten, wie schnell ihre Installation ist, welcher Server sie schneller ausliefert und ob eine Änderung sie langsamer gemacht hat. exp:benchmark wird mit Exponential 6.0.15 ausgeliefert. Es braucht nichts außer PHP mit der curl-Erweiterung: kein ab, kein wrk, keinen externen Dienst.

Es kann vier Dinge:

• http (Standard): ruft Seiten ab und misst ihre Zeit, gegen einen Server oder mehrere unmittelbar nacheinander (A/B).
• kernel: misst die Teile einer Seite innerhalb von PHP, ohne HTTP: Bootvorgang, Template-Rendering kalt und warm, Laden der INI-Dateien, Abruf von Inhalten, Knotenliste, Datenbank-Roundtrip, Schreiben und Lesen im Cache, Nachschlagen eines Bild-Alias.
• micro: misst reine PHP-Hotpaths des Kernels ohne Webserver und ohne Datenbank (Kompilieren und Rendern von Templates, Parsen von INI-Dateien, Autoload, eZURI, Übersetzungen, Validierung von Datentypen), normalisiert gegen eine Kalibrierungsschleife, sodass sich Läufe auf verschiedenen Rechnern vergleichen lassen. Die CI des Repositorys führt ihn bei jedem Push aus.
• baseline: speichert einen Lauf als JSON, vergleicht einen späteren Lauf damit und endet mit Status 1, wenn sich eine Kennzahl um mehr als einen Schwellenwert verschlechtert hat. Genau das prüft ein CI-Job oder ein Deployment-Skript.

Schnellstart, im Wurzelverzeichnis von Exponential:

./console exp:benchmark --allow-root-user                 # 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 ... ist derselbe Befehl ohne die Konsole.

Diese Seite ist die Referenz. Der Leitfaden Benchmarking von Exponential erklärt jede Verwendung Schritt für Schritt mit echten Beispielausgaben: die Zahlen lesen, Läufe fair vergleichen, Abläufe für Codeänderungen, Engines und Deployments, die Tempokarte der Tour, die CI-Prüfung und die Fehlersuche.

Standardmäßig sicher #

Ein Benchmark ist Last. Diese Regeln sorgen dafür, dass ein erster Versuch einer Website nicht schadet:

--cold-clear ist die einzige Option, die schreibt: Sie leert vor dem Lauf den Inhaltsansichts-Cache dieser Installation. Für einen Server, den die Installation nicht bedient, wird sie abgelehnt. Verwenden Sie sie nicht auf einem Server, an dem andere arbeiten; --cold misst an den Caches vorbei, ohne etwas zu leeren.

HTTP-Modus #

Was abgerufen wird #

Ohne --url wird die Liste aus der Website selbst gebildet:

1. die Startseite /;
2. die ersten Seiten des Menüs, also Inhaltsseiten: die Kinder des Startseitenknotens ([SiteSettings] IndexPage), die einen URL-Alias haben, nach Priorität und dann nach Knoten-ID (--pages=3, --pages=0 für keine);
3. die Suchseite /content/search?SearchText=<word>, wenn anonyme Besucher suchen dürfen (die Ansicht benötigt content/read, oder content/search steht in [RoleSettings] PolicyOmitList). Das Wort ist das erste Wort im Namen der ersten Menüseite oder --search=<words>; --no-search lässt die Seite weg;
4. die Anmeldeseite des Admins /<admin siteaccess>/user/login, wenn Siteaccesses über die URI zugeordnet werden (--no-admin, um sie wegzulassen).

Liste und Reihenfolge sind in jedem Lauf gleich, solange der Inhalt gleich ist, sodass zwei Läufe dieselben Seiten in derselben Reihenfolge messen. Für eine Liste, die sich nie ändert, nennen Sie die Seiten in einer Datei (--urls-file) und bewahren diese Datei zusammen mit der Baseline auf.

Der Server ist https:// plus die SiteURL des Siteaccess (-s/--siteaccess wählt einen anderen) oder --base=<url>.

Nennen Sie stattdessen Ihre eigenen Seiten:

./console exp:benchmark --url=/ --url=/news --url=/news/some-article --allow-root-user
./console exp:benchmark --urls-file=benchmark-urls.txt --allow-root-user   # one URL or path per line, # comments
./console exp:benchmark --url=https://staging.example.com/ --allow-root-user  # an absolute URL names its server

Warm und kalt #

--cold nutzt weiterhin den Ansichts-Cache und die kompilierten Templates, wie es die meisten echten Cache-Fehlschläge tun. Um ein Rendering mit leerem Ansichts-Cache zu messen, leert --cold-clear ihn einmal vor dem Lauf und lässt das Aufwärmen aus; dann ist die erste Anfrage jeder Seite die teure, und das zeigt sich in max und p99.

Die Spalte cache zählt den Header X-Exp-Cache (oder X-Cache) der Antworten: HIT:100 bedeutet, dass jede Anfrage aus dem Antwort-Cache beantwortet wurde, BYPASS:50, dass am Cache vorbeigegangen wurde, -, dass der Server keinen solchen Header gesendet hat.

Server vergleichen (A/B) #

./console exp:benchmark --compare=https://www.example.com,https://www.example.com:8080 --allow-root-user

Jede Seite wird von jedem Server abgerufen, und die zweite Tabelle stellt sie nebeneinander:

  A/B, measured back to back (B/A below 1 means B is faster for the median, above 1 more req/s):
  url       A                 B                      A median  B median    B/A  A req/s  B req/s    B/A
  /         www.example.com   www.example.com:8080       9.86      2.08  x0.21      368     1327  x3.61

So bleibt der Vergleich fair:

• Unmittelbar nacheinander. Die Anfragen einer Seite werden in Runden aufgeteilt (--rounds=2). In jeder Runde erhält jeder Server seinen Anteil, einer nach dem anderen, und die Reihenfolge wird in jeder zweiten Runde umgekehrt. Wird der Rechner nach der Hälfte stärker belastet, spüren das beide Server; keiner wird nur in der ruhigen Minute gemessen.
• Derselbe Client, dieselben Verbindungen. Ein Verbindungspool pro Server für den ganzen Lauf, geöffnet während des Aufwärmens (das mindestens eine Anfrage pro Verbindung umfasst), sodass keine gemessene Anfrage einen TLS-Handshake bezahlt. Mit --no-keepalive öffnet jede Anfrage eine neue Verbindung; das verwenden Sie, um den Handshake zu messen.
• Dieselbe Anfrage. Dieselben Header, dasselbe Accept-Encoding (standardmäßig gzip, --encoding=br, --encoding=none), dieselbe HTTP-Version (was curl aushandelt, oder --http=1.1 / --http=2).

Beurteilen Sie einen A/B-Vergleich nur anhand von Läufen, die unmittelbar nacheinander gemacht wurden. Auf einem geteilten Rechner verschiebt die Hintergrundlast die Ergebnisse von einer Sitzung zur nächsten um 10 bis 30 %; eine Zahl von heute Morgen, verglichen mit einer von heute Abend, sagt mehr über den Rechner als über die Server.

Weitere Optionen #

Wiederholbare Läufe #

Eine Zahl bedeutet nur etwas neben einer anderen, die auf dieselbe Weise gemessen wurde. Was zwei Läufe vergleichbar hält:

• Feste Anzahlen. --warmup=N ungemessene Anfragen, dann --runs=N gemessene pro Seite und Server (Kernel: --repeat, Micro: --repeat und --warmup). Halten Sie sie von Lauf zu Lauf gleich; mehr Läufe machen p99 stabiler (bei 100 Läufen ist p99 fast das Maximum, bei 1000 sagt es etwas aus).
• Dieselben Seiten, dieselbe Reihenfolge. Die Standardliste wird jedes Mal gleich gebildet (siehe oben); --urls-file legt sie fest.
• Jede Statistik. Median, p90, p99, Minimum, Maximum und die Standardabweichung (sd, Stichprobe, n - 1) für jede Zeile, in der Tabelle, in --format=json und in --format=csv.
• Die Umgebung wird festgehalten. --format=json und --save schreiben neben die Zeilen einen Block environment:

"environment": {
    "date": "2026-10-06T02:30:26Z", "php": "8.5.11", "sapi": "cli", "engine": "php-cli",
    "opcache": false, "jit": false, "xdebug": false, "os": "Linux 5.14.0-687.5.3.el9_8.x86_64",
    "arch": "x86_64", "machine": "web.example.com", "cpus": 12, "load": 9.59,
    "exponential": "6.0.15stable", "git_commit": "3a5029891ec19884b64c8bf8e6bbeeb793b57c61", "ci": ""
}

opcache und engine beschreiben das PHP, das den Benchmark ausgeführt hat (im HTTP-Modus ist das der Client; die gemessenen Server werden pro Zeile anhand ihres Headers Server im Feld server genannt). Der Commit wird aus .git gelesen, ohne git auszuführen (einschließlich eines verknüpften Worktrees und gepackter Refs), oder aus GITHUB_SHA. Ein Vergleich mit einer Baseline, die unter einer anderen PHP-Minor-Version oder einer anderen Einstellung für OPcache, JIT oder Xdebug entstanden ist, gibt einen Hinweis aus, der den Unterschied nennt, denn dann werden die Konfigurationen verglichen, nicht der Code.

Rauschen und wie Sie es verringern #

Kernel-Modus #

./console exp:benchmark kernel --allow-root-user
./console exp:benchmark kernel --repeat=50 --node=144 --allow-root-user
./console exp:benchmark kernel --probe=render_warm --probe=db_query --allow-root-user

boot, process und render_cold starten --boot-repeat=5 Prozesse; jede andere Messung läuft --repeat=20-mal. Ohne --node verwenden die Render-Messungen die Startseite, es sei denn, deren vollständige Ansicht ist fast leer (eine aus Layout-Blöcken aufgebaute Startseite rendert diese im Seitenlayout, nicht in der vollständigen Ansicht); dann die Menüseite mit der größten vollständigen Ansicht. Die Spalte note nennt, was verwendet wurde. mem peak ist der Speicher, den die Messung über das zuvor Belegte hinaus benötigte (unter PHP 8.0 und 8.1, die den Spitzenwert nicht zurücksetzen können, ist es der bisherige Spitzenwert des Prozesses).

Kernel-Zahlen geben an, was eine Anfrage kostet, bevor Webserver, Antwort-Cache und Netzwerk etwas hinzufügen oder abziehen. Verwenden Sie sie, um zu sehen, was eine Codeänderung kostet, und HTTP-Zahlen, um zu sehen, was ein Besucher bekommt.

Micro-Modus #

./console exp:benchmark micro --allow-root-user
./console exp:benchmark --micro --repeat=50 --warmup=5 --allow-root-user
./console exp:benchmark micro --probe=template_compile --probe=ini_parse --allow-root-user
php bin/php/benchmark.php micro --format=json > micro.json      # without the console

Kein Webserver, keine Datenbank, kein Antwort-Cache: nur PHP und der Code des Kernels, daher läuft er gleich auf einem Laptop, einem Server und einem CI-Runner. Jede Messung leistet pro Iteration eine feste Menge Arbeit, läuft --warmup=3 Iterationen ungemessen und --repeat=30 gemessen.

Geschrieben werden nur kompilierte Templates und ein Fixture-Template in einem Verzeichnis des Cache-Verzeichnisses (benchmark-micro/), das am Ende entfernt wird.

  probe               n   ops   min  median   p90   p99   max    sd    ops/s  x calib  err  note
  template_compile   30     5  56.6    65.3  82.6  85.6  85.9  8.94     76.6    6.978    0  5 shipped templates, ...
  ini_parse          30     7  4.32    5.23  5.87  6.13  6.16  0.47     1337    0.559    0  7 files of settings/ ...
  i18n_lookup        30  3000  3.27    3.39  3.77  4.08  4.12  0.22   885768    0.362    0  300 messages of ger-DE, 10 times

• Zeiten sind Millisekunden pro Iteration; ops ist die Arbeit, die eine Iteration leistet, ops/s die Operationen pro Sekunde beim Median.
• x calib ist der Median geteilt durch den Median der Kalibrierungsschleife: feste reine PHP-Arbeit (Ganzzahlarithmetik, Aufbau von Zeichenketten, Sortieren, ein regulärer Ausdruck, Hashing, ein assoziatives Array), gemessen vor und nach den Messungen im selben Prozess. Auf einem doppelt so schnellen Rechner halbieren sich beide, und das Verhältnis bleibt; dieses Verhältnis vergleicht die CI-Prüfung. Die Kopfzeile gibt den Kalibrierungsmedian und seine Drift zwischen vorher und nachher an; eine Drift von mehr als etwa 10 % bedeutet, dass sich die Last des Rechners während des Laufs geändert hat.

Die Ergebnisse lesen #

  target                 url    n   min  median   p90   p99   max    sd  req/s  err  status  bytes  cache
  www.example.com        /     40  7.51    10.7  18.0  29.7  30.1  5.31    307    0  200:40  16.6k  HIT:40
  www.example.com:8080   /     40  1.16    2.55  3.44  4.17  4.35  0.69   1110    0  200:40  15.3k  HIT:40

• Zeiten sind Millisekunden, von curl selbst für jede Anfrage gemessen (vom Beginn der Anfrage bis zum letzten Byte), nicht von der Schleife darum herum.
• median ist die typische Anfrage. p90 und p99 geben an, wie lange die langsamsten 10 % und 1 % mindestens warten; sie zeigen Warteschlangen, Garbage Collection, einen abgelaufenen Cache (p95 steht in der JSON- und CSV-Ausgabe). sd ist die Standardabweichung: klein im Vergleich zum Median bedeutet gleichmäßige Antworten, so groß wie der Median bedeutet, dass der Lauf verrauscht war oder die Seite mal gerendert wird und mal aus einem Cache kommt. Perzentile werden zwischen den beiden nächstgelegenen Messwerten interpoliert, nach der Methode von numpy, R Typ 7 und Excel PERCENTILE.INC. Bei 100 Anfragen liegt p99 nahe am Maximum.
• req/s sind die erfolgreichen Anfragen geteilt durch die Zeit, die die Durchgänge gedauert haben. Der Wert hängt von --concurrency ab: vier gleichzeitig und je 10 ms können etwa 400 nicht überschreiten.
• err zählt Transportfehler und Antworten ab 400; die Zeilen unter der Tabelle nennen sie. Eine abgelehnte Verbindung hat keine Zeit und bleibt bei den Zeitmessungen außen vor, sodass ein defekter Server nie schnell wirkt.
• bytes ist die mittlere Größe einer Antwort, wie sie übertragen wurde (komprimiert, wenn der Server komprimiert hat).

Am meisten zählt meist der Unterschied zwischen einem Cache-Treffer und einem Rendering, der ein bis zwei Größenordnungen beträgt. Gemessen auf dem Demonstrationsserver am 5. Oktober 2026 (12 Kerne, mit anderer Arbeit geteilt, Last etwa 8), 100 Anfragen pro Seite, Parallelität 4:

Der Antwort-Cache entscheidet also über den größten Teil dessen, worauf ein Besucher wartet, und eine einzelne Zahl „welcher Server ist schneller“ führt in die Irre: Die Reihenfolge der beiden Server war bei den meisten Seiten für gecachte und für gerenderte Seiten umgekehrt.

Einen Lauf speichern und Verschlechterungen erkennen #

mkdir -p var/benchmark
./console exp:benchmark --save=var/benchmark/baseline.json --allow-root-user
# ... deploy a change ...
./console exp:benchmark --baseline=var/benchmark/baseline.json --allow-root-user
echo $?        # 0 no regression, 1 a metric regressed, 2 usage error or refused

Zeilen werden nach Server und Pfad zugeordnet (Kernel-Zeilen nach dem Namen der Messung). Eine Kennzahl gilt als verschlechtert, wenn:

Die Rauschgrenze gibt es, weil kleine Zahlen springen: Ein Datenbank-Roundtrip von 0,2 ms, der einmal 0,3 ms dauert, ist 50 % langsamer und bedeutet nichts. Eine Seite, die im neuen Lauf fehlt, wird aufgeführt, aber nicht gezählt. --all-checks zeigt jeden Vergleich, nicht nur die Verschlechterungen.

Zwei gespeicherte Läufe lassen sich vergleichen, ohne etwas zu messen, und ein gespeicherter Lauf lässt sich erneut ausgeben:

./console exp:benchmark compare var/benchmark/baseline.json var/benchmark/today.json --allow-root-user
./console exp:benchmark show var/benchmark/today.json --allow-root-user

In der CI #

Das Repository führt den Micro-Modus bei jedem Push und Pull Request aus, der PHP, Templates, Einstellungen oder den Benchmark selbst betrifft: der Workflow .github/workflows/performance.yml, Job „Micro benchmark (PHP 8.5)“.

php bin/php/benchmark.php micro --repeat=30 --warmup=3 --baseline=tests/benchmark/baseline.json --all-checks

• Normalisiert. CI-Runner unterscheiden sich von Lauf zu Lauf in der Geschwindigkeit. Ein Micro-Lauf wird mit der Baseline verglichen, nachdem der Median jeder Messung durch den eigenen Kalibrierungsmedian des Laufs geteilt wurde; ein langsamerer Runner ist also keine Verschlechterung, eine Messung, die relativ zur Kalibrierungsschleife langsamer wurde, schon. Der Vergleich gibt die Geschwindigkeit dieses Rechners gegenüber der der Baseline aus (x0.86 = 14 % langsamer) und pro Messung die normalisierten Mediane und ihre Änderung.
• Nachsichtig. Nur eine Messung, die nach der Normalisierung mehr als 40 % langsamer ist, zählt (--threshold=40 ist der Standard für micro; http und kernel behalten 15). Eine Micro-Messung, die fehlschlägt oder häufiger fehlschlägt als in der Baseline, zählt ebenfalls.
• Nur eine Warnung. Der Workflow ist von PHPUnit und Quality getrennt, und sowohl sein Job als auch der Benchmark-Schritt haben continue-on-error: true: Eine Verschlechterung erscheint als Warnungsannotation und in der Job-Zusammenfassung, die Prüfung bleibt grün, und die Haupt-CI kann dadurch weder rot noch unzuverlässig werden. Der Lauf wird als Artefakt benchmark-micro aufbewahrt.
• Zur Pflicht machen, sobald mehrere Läufe auf main deutlich innerhalb des Schwellenwerts geblieben sind: Entfernen Sie die beiden Zeilen continue-on-error: true aus performance.yml und nehmen Sie „Micro benchmark (PHP 8.5)“ in die erforderlichen Statusprüfungen des Branch-Schutzes von main auf. Erhöhen oder senken Sie --threshold im selben Schritt, wenn die Läufe zeigen, dass es nötig ist.

Die Baseline erneuern, nach einer Änderung, die die Geschwindigkeit ändern soll, nach dem Hinzufügen einer Messung oder wenn PHP aktualisiert wird. Am besten aus einem CI-Lauf von main, der dort misst, wo die Prüfung läuft:

gh run list --workflow=performance.yml --branch=main --limit=5
gh run download <run id> -n benchmark-micro -D var/tmp/benchmark-micro
cp var/tmp/benchmark-micro/benchmark-micro.json tests/benchmark/baseline.json

oder lokal, auf einem ruhigen Rechner mit PHP 8.5, OPcache für die CLI ausgeschaltet (php -d opcache.enable_cli=0, der Standard) und ohne Xdebug:

php bin/php/benchmark.php micro --save=tests/benchmark/baseline.json

Committen Sie tests/benchmark/baseline.json für sich allein mit einer Nachricht, die sagt, warum sich die Geschwindigkeit geändert hat.

Die Modi http und kernel funktionieren in der CI genauso, ohne die Normalisierung:

./console exp:benchmark kernel --repeat=30 --baseline=ci/benchmark-kernel.json --threshold=20 --format=json \
    --allow-root-user > benchmark.json

• --format=json gibt den ganzen Lauf (Einstellungen, Umgebung, Zeilen, den Vergleich) auf stdout aus; --format=csv gibt die Zeilen aus. Der Fortschritt geht nach stderr, sodass die Ausgabe weitergeleitet werden kann. -q unterdrückt den Fortschritt und behält das Ergebnis. Auf GitHub Actions wird jede Verschlechterung zusätzlich als Annotation ::warning ausgegeben.
• Messen Sie auf demselben Rechner wie die Baseline, ohne dass etwas anderes läuft, und bewahren Sie die Baseline im Repository des Projekts auf, nicht in var/. Eine Baseline von einem anderen Rechner vergleicht die Rechner.
• Der Kernel-Modus ist stabiler als http: kein Netzwerk, kein Webserver, kein Antwort-Cache. Der HTTP-Modus auf einem CI-Runner, der seinen eigenen Server startet (php -S, Velocity, ein Container), funktioniert mit --base=http://127.0.0.1:<port>; für Loopback gibt es keine Obergrenze an Anfragen.
• Cache-Treffer von 1 bis 3 ms schwanken auf einem ausgelasteten Rechner von Lauf zu Lauf um mehr als 15 %. Erhöhen Sie dafür --threshold oder --min-delta, oder prüfen Sie gerenderte Seiten mit --cold, deren Zahlen größer und stabiler sind.

Das gespeicherte Format hat eine Version ("format": 1); eine Baseline einer anderen Version wird abgelehnt, statt falsch verglichen zu werden.

Dateien #

Die Tests ausführen: php vendor/bin/phpunit tests/tests/kernel/classes/benchmark/.

Verwandte Seiten #

• Benchmarking von Exponential: der Leitfaden, vom ersten Lauf bis zur CI-Prüfung.
• Konsole: jeder Befehl.
• Velocity-Engines: die Server, die Sie vergleichen möchten.
• HTTP-Caching und Cache-Aufwärmung: was die warmen Zahlen messen.