Topic starter
25/10/2026 11:07 am
TL;DR: Rule-set scope, not the WAF engine, drives most of the latency, CPU, and memory cost, Tetrate finds. WAF capacity planning changes when full OWASP CRS body inspection is on the route, because heavier policies can reshape p99 headroom.
Editorial analysis by NHI Mgmt Group, based on content published by Tetrate: “Get a High-Performance WAF With Better Rules: Benchmarks on Rules vs. Engine”.
By the numbers:
- Full OWASP CRS on 1 KB bodies sustained about 1,000 RPS per 6-core instance with a 4.86 ms p99 on TEG WAF.
- Full CRS on larger bodies drove CPU cost to about 18.15 cores per 1,000 RPS at 50 KB.
- Peak memory stayed under 80 MB with targeted rules but rose to 100-205 MB under full CRS.
Key questions
Q: Why does full OWASP CRS cost so much more than targeted WAF rules?
A: Full CRS evaluates hundreds of checks against every request, including body parsing and rule-phase execution.
Q: What are the signs that a WAF policy is too broad for production?
A: Watch for rising p99 latency, CPU saturation, and memory growth when request bodies are enabled or when broad rule groups are added.
Q: How should teams size a WAF when rule sets vary by route?
A: Size it by the heaviest policy that a route will actually carry, then validate the p99 latency and CPU headroom at that depth.
Practitioner guidance
- Measure WAF cost by rule tier, not by brand Benchmark header-only, targeted, and full-CRS policies separately so capacity planning reflects the actual inspection depth you intend to run.
- Scope body inspection to the routes that need it Apply request-body parsing and deep inspection only to endpoints that carry meaningful attack exposure, such as login, upload, and API submission paths.
- Set latency budgets before enabling broad CRS coverage Define acceptable p99 latency and CPU ceilings for each application class before enabling full OWASP CRS across production traffic.
Bottom line: The article shows that WAF performance is constrained more by rule-set scope than by the underlying engine choice.
Glossary terms: Web Application Firewall, Request-Body Inspection, OWASP Core Rule Set, Tail Latency
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:16 pm
Rule-set scope is the real control boundary: the benchmark shows that WAF performance is governed far more by policy breadth than by the engine itself. That means the operational question is not which proxy is faster, but which routes deserve body inspection, injection detection, and full CRS coverage. For security programmes, this is a control-design issue, not a vendor choice issue.
A question worth separating out:
Q: Should security teams prioritise selective inspection over blanket CRS coverage?
A: Yes, unless every protected route has the same exposure and latency tolerance. Most environments do not. Selective inspection lets teams reserve heavy-body parsing and high-paranoia rules for the few paths that need them, while keeping the rest of the traffic on a lighter policy.
👉 Read our full editorial: WAF performance depends more on rules than engine choice
This post was modified 7 days ago by NHI Mgmt Group