Як ми вимірюємо затримку WAF — і чому підписуємо кожну цифру

Цифра чесна лише тоді, коли ви можете сказати, як її отримали

«Практично нульова затримка» — стандартна фраза для безпекового edge. І вона ж непроверна: за нею немає методики, тож нема чого перевіряти. Ми радше опублікуємо реальну цифру разом із методом і чітко вкажемо, на якому обладнанні вона отримана. Ця сторінка — і є той метод.

Що ми насправді вимірюємо

Важлива саме додана затримка: час, який наш WAF витрачає на інспекцію запиту, поверх мережевого раунд-тріпу, який ви платили б у будь-якому разі. Ми вимірюємо це на трьох рівнях.

• На кожен запит, на edge. Кожен оброблений WAF запит фіксує власний час інспекції в мікросекундах — значення waf_processing_time_us у нашому логу запитів. Це і є вартість фільтрування окремо: розбір, оцінка правил, рішення драбини challenge. Для звіту ми переводимо мікросекунди в мілісекунди й ніколи не округлюємо суб-мілісекундну цифру вгору до «гарнішого» числа.
• Розподіл, а не одна вдала вибірка. Медіана ховає хвіст, а саме у хвості реальні користувачі відчувають затримку. Ми рахуємо і медіану, і P99 перцентильним запитом (percentile_disc) по фактичних рядках логу у виміряному вікні — не синтетичне середнє й не вручну підібраний найкращий випадок.
• Наскрізно, крізь edge. Мікросекунди на запит нічого не кажуть про досвід завантаження сторінки, тож ми ще запускаємо Lighthouse-стенд, який вантажить реальну сторінку крізь edge і порівнює з прямим завантаженням того самого origin. Це вловлює те, чого ізольований таймер не бачить: TLS, буферизацію, перевикористання з’єднань.

Проєктний бюджет

Наша інженерна ціль — ≤5 мс доданої затримки на нормальному трафіку. Це проєктний бюджет, навколо якого побудовано весь data-plane: кеші у спільній памʼяті перед Redis, жодного блокуючого вводу-виводу на шляху запиту, один прохід WAF на запит. Це число, якого ми тримаємось, і причина, чому архітектура виглядає саме так.

Що означають поточні цифри — читайте підпис

Кожна опублікована сьогодні цифра затримки — виміряна на staging, на одному вузлі з 1 vCPU. Наш staging-edge — це один невеликий VPS. Його достатньо, щоб довести методику, прогнати весь конвеєр фільтрування й отримати реальні перцентилі — але він упирається в CPU, а одноядерна машина не є продакшн-edge. Тому ми кажемо про це щоразу, поруч із цифрою. Актуальне значення — на нашій сторінці стану edge, згенероване тим самим запитом до логів, описаним вище.

Чого ми не стверджуємо

Наша повна ціль продуктивності — тримати високу пропускну здатність за жорсткого P99 на продакшн-обладнанні — це бенчмарк, якого ми не проганяли, бо staging-вузол його не потягне. Цей результат на продакшн-парку заблокований обладнанням, і поки він не пройде на реальному edge, ми не подаємо жодну цифру як продакшн-результат. Staging-цифра з чесним підписом вартує більше, ніж продакшн-цифра, за яку ми не можемо поручитися.

Уся суть — саме в цій стриманості. Якщо вам потрібен WAF, який чітко каже, що саме він виміряв і на якому обладнанні, назвіть свій домен.