Comment nous mesurons la latence du WAF — et pourquoi nous étiquetons chaque chiffre

Un chiffre n’est honnête que si l’on peut dire comment on l’a obtenu

« Latence quasi nulle » est la formule standard pour un edge de sécurité. Elle est aussi infalsifiable : aucune méthode ne la sous-tend, il n’y a donc rien à vérifier. Nous préférons publier un chiffre réel, avec la méthode attachée, et indiquer exactement le matériel qui l’a produit. Cette page, c’est cette méthode.

Ce que nous mesurons réellement

Ce qui compte, c’est la latence ajoutée : le temps que notre WAF passe à inspecter une requête, en plus de l’aller-retour réseau que vous paieriez de toute façon. Nous la mesurons à trois niveaux.

• Par requête, à l’edge. Chaque requête traitée par le WAF enregistre son propre temps d’inspection en microsecondes — la valeur waf_processing_time_us inscrite dans notre log de requêtes. C’est le coût du filtrage isolé : parsing, évaluation des règles, décision de l’échelle de défis. Pour le rapport, nous convertissons les microsecondes en millisecondes et n’arrondissons jamais un chiffre sub-milliseconde vers un nombre plus flatteur.
• Une distribution, pas un échantillon chanceux. La médiane masque la queue de distribution, et c’est dans cette queue que les vrais utilisateurs ressentent la latence. Nous calculons la médiane et le P99 avec une requête de percentile (percentile_disc) sur les lignes de log réelles d’une fenêtre mesurée — pas une moyenne synthétique, pas un meilleur cas trié à la main.
• De bout en bout, à travers l’edge. Un compteur de microsecondes par requête ne dit rien de l’expérience de chargement, alors nous exécutons aussi un banc Lighthouse qui charge une vraie page à travers l’edge et la compare au chargement direct du même origine. Cela capture ce que le minuteur isolé ne voit pas : TLS, bufferisation, réutilisation des connexions.

Le budget de conception

Notre objectif d’ingénierie est de ≤5 ms de latence ajoutée sur du trafic normal. C’est un budget de conception autour duquel tout le data-plane est bâti : caches en mémoire partagée devant Redis, aucune E/S bloquante sur le chemin de la requête, un seul passage WAF par requête. C’est le chiffre que nous nous imposons, et la raison pour laquelle l’architecture est ce qu’elle est.

Ce que signifient les chiffres actuels — lisez l’étiquette

Chaque chiffre de latence publié aujourd’hui est mesuré en staging, sur un unique nœud à 1 vCPU. Notre edge de staging est un petit VPS. Il suffit à prouver la méthode, à exercer toute la chaîne de filtrage et à produire de vrais percentiles — mais il est limité par le CPU, et une machine mono-cœur n’est pas un edge de production. Nous le disons donc à chaque fois, juste à côté du chiffre. La valeur en direct se trouve sur notre page d’état de l’edge, générée à partir de la même requête de logs décrite ci-dessus.

Ce que nous n’affirmons pas

Notre objectif complet de performance — soutenir un débit élevé à un P99 serré sur du matériel de production — est un banc d’essai que nous n’avons pas exécuté, car le nœud de staging n’en est pas capable. Ce résultat sur une flotte de production est bloqué par le matériel, et tant qu’il ne tourne pas sur du vrai matériel edge, nous ne présentons aucun chiffre comme un résultat de production. Un chiffre de staging honnêtement étiqueté vaut plus qu’un chiffre de production dont nous ne pourrions pas répondre.

Cette retenue est tout l’enjeu. Si vous voulez un WAF qui vous dit exactement ce qu’il a mesuré et sur quel matériel, donnez-nous votre domaine.