Wie wir WAF-Latenz messen — und warum wir jede Zahl kennzeichnen

Eine Zahl ist nur ehrlich, wenn man sagen kann, wie sie zustande kam

„Praktisch null Latenz“ ist der Standardsatz für eine Security-Edge. Er ist zugleich unwiderlegbar: Es steckt keine Methode dahinter, also gibt es nichts zu prüfen. Wir veröffentlichen lieber eine echte Zahl samt Methode und kennzeichnen genau, welche Hardware sie erzeugt hat. Diese Seite ist genau diese Methode.

Was wir tatsächlich messen

Entscheidend ist die zusätzliche Latenz: die Zeit, die unsere WAF für die Inspektion einer Anfrage aufwendet — obendrauf auf den Netzwerk-Roundtrip, den Sie ohnehin zahlen. Das messen wir auf drei Ebenen.

• Pro Anfrage, an der Edge. Jede von der WAF verarbeitete Anfrage protokolliert ihre eigene Inspektionszeit in Mikrosekunden — den Wert waf_processing_time_us in unserem Request-Log. Das sind die Filterkosten isoliert: Parsing, Regelauswertung, die Entscheidung der Challenge-Leiter. Für den Bericht rechnen wir Mikrosekunden in Millisekunden um und runden eine Sub-Millisekunden-Zahl niemals auf einen freundlicher aussehenden Wert auf.
• Verteilung statt einer glücklichen Stichprobe. Der Median verbirgt den Tail — und im Tail spüren echte Nutzer die Latenz. Wir berechnen Median und P99 mit einer Perzentil-Abfrage (percentile_disc) über die tatsächlichen Log-Zeilen in einem gemessenen Fenster — kein synthetischer Mittelwert, kein handverlesener Bestfall.
• Ende zu Ende, durch die Edge. Ein Mikrosekunden-Zähler pro Anfrage sagt nichts über das Seitenerlebnis, deshalb betreiben wir zusätzlich einen Lighthouse-Prüfstand, der eine echte Seite durch die Edge lädt und mit dem direkten Laden desselben Origin vergleicht. Das erfasst, was der isolierte Timer nicht sieht: TLS, Pufferung, Verbindungswiederverwendung.

Das Design-Budget

Unser Engineering-Ziel sind ≤5 ms zusätzliche Latenz bei normalem Verkehr. Das ist ein Design-Budget, um das die gesamte Data-Plane herum gebaut ist: Shared-Memory-Caches vor Redis, kein blockierendes I/O im Anfragepfad, ein einziger WAF-Durchlauf pro Anfrage. An diese Zahl halten wir uns — und sie ist der Grund, warum die Architektur so aussieht, wie sie aussieht.

Was die aktuellen Zahlen bedeuten — lesen Sie die Kennzeichnung

Jede heute veröffentlichte Latenzzahl ist staging-gemessen auf einem einzelnen 1-vCPU-Knoten. Unsere Staging-Edge ist ein kleiner VPS. Er genügt, um die Methode zu belegen, die gesamte Filter-Pipeline durchzuspielen und echte Perzentile zu erzeugen — aber er ist CPU-gebunden, und eine Ein-Kern-Maschine ist keine Produktions-Edge. Also sagen wir das jedes Mal, direkt neben der Zahl. Der Live-Wert steht auf unserer Edge-Statusseite, erzeugt aus derselben Log-Abfrage, die oben beschrieben ist.

Was wir nicht behaupten

Unser volles Performance-Ziel — hoher Durchsatz bei engem P99 auf Produktionshardware — ist ein Benchmark, den wir nicht gefahren haben, weil der Staging-Knoten ihn nicht schafft. Dieses Ergebnis auf einer Produktionsflotte ist hardware-blockiert, und solange es nicht auf echter Edge-Hardware läuft, geben wir keine Zahl als Produktionsergebnis aus. Eine Staging-Zahl mit ehrlicher Kennzeichnung ist mehr wert als eine Produktionszahl, für die wir nicht geradestehen können.

Genau diese Zurückhaltung ist der Punkt. Wenn Sie eine WAF wollen, die Ihnen genau sagt, was sie gemessen hat und auf welcher Hardware, nennen Sie uns Ihre Domain.