Benchmark einer gehosteten Website #

Diese Seite ist für Systemadministratoren und Produktmanager bei Hosting-Anbietern, die sagen müssen, wie schnell eine Kunden-Website ist, zwei Server-Einrichtungen vergleichen, beweisen, dass ein Ausrollen nichts langsamer gemacht hat, oder die Grenzen eines Tarifs festlegen. Sie beantwortet: was exp:benchmark misst, wie Sie es sicher auf Produktionsmaschinen nutzen, wie Sie fair vergleichen und wie Sie aus den Zahlen Entscheidungen machen. Die Quellen sind Benchmark von Exponential und Benchmark: exp:benchmark.

Inhalt #

1. Was es misst und was nicht
2. Standardmäßig sicher
3. Der erste Lauf
4. Zwischengespeichert und gerendert
5. Zwei Einrichtungen vergleichen
6. Ein Ausrollen prüfen
7. Rauschen auf geteilten Maschinen
8. Von Messungen zu Grenzen von Tarifen
9. Checkliste

Was es misst und was nicht #

Es beantwortet nicht, wie viele Besucher diese Maschine verkraftet; dafür braucht es einen Lastgenerator gegen eine Kopie der Website. --tool=ab|wrk|oha übergibt die Anfragen an einen installierten Lastgenerator und ist der Anfang davon, nicht das Ende.

Standardmäßig sicher #

• Der HTTP-Modus sendet nur GET, schickt nie etwas ab, keine Cookies ohne --cookie.
• Gegen einen anderen Host als die Loopback-Adresse dieser Maschine brauchen mehr als 1000 Anfragen pro URL, mehr als 16 gleichzeitig, ein Vorwärmen über 100 oder insgesamt mehr als 20.000 Anfragen --force.
• Die Standardliste der Seiten wird nur an Hosts gesendet, die diese Installation ausliefert; ein anderer Host muss mit --url genannt werden.
• --cold-clear ist die eine Option, die etwas leert (den Content-View-Cache, einmal); sie wird für Server verweigert, die die Installation nicht ausliefert. Nutzen Sie sie nicht auf einem Server, auf dem andere arbeiten.
• Als root ausgeführt, gibt der Befehl eine Warnung aus und wartet zehn Sekunden; führen Sie ihn, wo Sie können, als Benutzer der Website aus.

Der erste Lauf #

Aus dem Wurzelverzeichnis der Installation:

./console exp:benchmark --allow-root-user

Er fragt die Startseite, die ersten drei Menüseiten, die Suchseite (wenn Besucher suchen dürfen) und die Anmeldeseite der Administration an, jeweils 100-mal nach 5 Anfragen zum Vorwärmen, 4 gleichzeitig, und gibt pro Seite Median, p90, p99, Minimum, Maximum und Standardabweichung aus, dazu die Umgebung (PHP, OPcache, Xdebug, CPUs, Last, Commit). Für eine Liste, die sich nie ändert, nennen Sie die Seiten:

./console exp:benchmark --urls-file=benchmark-urls.txt --allow-root-user

Zwischengespeichert und gerendert #

Die meisten Besucher bekommen die warme Zahl; Redakteure, Suchen und Cache-Fehlschläge bekommen die kalte. Berichten Sie beide.

Zwei Einrichtungen vergleichen #

Betreiben Sie beide Server auf derselben Installation (zum Beispiel Velocity auf einem eigenen Port neben Apache) und messen Sie sie in einem Lauf, direkt nacheinander:

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

Das eigene Beispiel der Anleitung zeigt, warum beide Läufe zählen: Zwischengespeichert antwortete Velocity in 1,3 bis 2,6 ms gegenüber 8,7 bis 10,7 ms von Apache; gerendert war Apache in diesem Lauf schneller. Eine einzelne Zahl dazu, welcher Server schneller ist, führt in die Irre (Benchmark, Abschnitt 4.4). Drei oder mehr Server lassen sich auf einmal vergleichen; jeder wird mit dem ersten verglichen.

Ein Ausrollen prüfen #

./console exp:benchmark --cold --runs=50 --save=var/benchmark/pre-deploy.json --allow-root-user
./console exp:velocity deploy --allow-root-user
php bin/php/warm.php --allow-root-user
./console exp:benchmark --cold --runs=50 --baseline=var/benchmark/pre-deploy.json --min-delta=5 --allow-root-user
echo $?        # 0 no regression, 1 a metric regressed, 2 usage error or refused

Eine Kennzahl gilt als verschlechtert, wenn sie um mehr als --threshold Prozent (15) und um mehr als --min-delta Millisekunden (1) gewachsen ist. Ein Skript zum Ausrollen kann den Exit-Code nutzen; geben Sie ihm auf einer geteilten Maschine --threshold=25 oder mehr und ein --min-delta, sonst schlägt es falschen Alarm (Benchmark, Abschnitt 11.5).

Rauschen auf geteilten Maschinen #

Die Anleitung wiederholte einen gespeicherten Lauf neun Minuten später ohne jede Änderung und bekam 13 „Verschlechterungen“: Die Maschine war ausgelasteter. Cache-Treffer von 1 bis 3 ms verdoppelten sich auf einer geteilten Maschine von einer Minute zur nächsten. Was zu tun ist (Benchmark, Abschnitt 10):

1. Dieselbe Maschine, dasselbe PHP, dieselbe Einstellung für OPcache, JIT und Xdebug (die Umgebungszeile sagt, welche).
2. Derselbe Befehl: dieselben Seiten, Läufe, dasselbe Vorwärmen, dieselbe Gleichzeitigkeit, warm oder kalt.
3. Nichts anderes läuft, das Sie anhalten können; notieren Sie die Last in der Kopfzeile.
4. Vorher und nachher dicht beieinander; für zwei Server ein Lauf mit --compare, nie zwei getrennte.
5. Die Caches im selben Zustand: dieselbe Spalte cache in beiden Läufen.
6. Führen Sie es zweimal aus. Ein Unterschied, der sich nicht wiederholt, ist Rauschen.
7. Beurteilen Sie zuerst den Median, p90 und p99 als Zweites, das Maximum nie allein.

Tipp Führen Sie nie einen Benchmark mit geladenem Xdebug aus (alles ist mehrfach langsamer); die Kopfzeile sagt Xdebug ON, wenn es geladen ist.

Von Messungen zu Grenzen von Tarifen #

Das Projekt veröffentlicht keine Kapazität pro Server, und diese Hilfe nennt keine. Was die Quellen geben, ist eine Methode:

Zahlen, die in der Dokumentation zitiert werden (zum Beispiel 8.941 Anfragen pro Sekunde im README oder die Zahlen zu Instanzen auf Velocity-Worker und Pools), wurden auf bestimmten Maschinen und Websites gemessen. Die Quellen sagen das: Sie beschreiben die Templates dieser Website auf dieser Maschine, sind keine Eigenschaft des Servers und sollten nicht als solche zitiert werden. Nehmen Sie sie nicht in einen Tarif oder ein Angebot auf.

Checkliste #

• To do: Benchmarks laufen als Benutzer der Website, gegen Hosts, die diese Installation ausliefert.
• To do: Jeder Bericht nennt warme und kalte Zahlen und die Umgebungszeile.
• To do: Vergleiche werden in einem Lauf mit --compare gemacht, direkt nacheinander.
• To do: Prüfungen nach dem Ausrollen nutzen --baseline mit einem --min-delta, das zu einer geteilten Maschine passt.
• To do: Grenzen von Tarifen stammen aus Ihren eigenen Messungen, nicht aus Zahlen der Dokumentation.

Verwandte Seiten #

• Leistung
• Velocity-Worker und Pools
• Hosting-Tarife gestalten
• Benchmark von Exponential
• Benchmark: exp:benchmark
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.