Skip to content
Notifications
Clear all

Has anyone benchmarked latency added by the CDN's 'always on' WAF?

2 Posts
2 Users
0 Reactions
0 Views
(@clarak)
Estimable Member
Joined: 2 weeks ago
Posts: 173
Topic starter   [#24496]

In our ongoing vendor evaluation for a consolidated web application and API protection platform, Imperva's Cloud WAF is a primary contender. A consistent point of discussion internally is the performance impact, specifically the latency introduced by routing all traffic through their global CDN for the "always-on" inspection model. While Imperva's marketing materials and sales engineering provide generalized latency figures (often quoting sub-10ms increases), I am inherently skeptical of vendor-supplied benchmarks.

I am seeking empirical, operational data from teams who have conducted before-and-after measurements in a production environment. I am particularly interested in scenarios that might reveal less-optimized paths or architectural nuances.

Key dimensions of the benchmark I'm analyzing include:
* **Geographic Baseline:** What was the origin latency (e.g., from a key user population to your AWS/Azure/GCP origin) prior to onboarding Imperva?
* **Traffic Profile:** Were you measuring simple static asset delivery, dynamic API calls, or complex POST requests with payload inspection?
* **Measurement Methodology:** Did you use synthetic monitoring (e.g., Catchpoint, ThousandEyes), real-user metrics (RUM), or log-based analysis? Comparing 95th or 99th percentile latency is crucial.
* **Configuration Specifics:** Did latency vary significantly with certain WAF rule sets enabled (e.g., the Imperva Core Rule Set vs. custom behavioral rules)? Was there a noticeable difference between "Block" and "Alert" modes for a given rule?
* **Cache Interaction:** For cacheable content, how effective was Imperva's CDN at mitigating the WAF inspection penalty? Was the observed latency additive or did the CDN benefit negate the WAF cost?

Our preliminary testing in a staging environment showed a median latency add of ~8ms for API calls from the US-East coast to a US-East origin, which is acceptable. However, the 99th percentile spikes were more concerning, occasionally adding 80-120ms. We are trying to determine if this is indicative of a routing issue, a specific rule evaluation, or an inherent characteristic of the service.

Any detailed findings, especially those that correlate latency with specific security policy complexities or traffic patterns, would be immensely valuable for our procurement committee's technical evaluation and subsequent SLA negotiations.



   
Quote
(@brian7)
Reputable Member
Joined: 3 weeks ago
Posts: 150
 

That's a great breakdown of what you're looking for. I'm also evaluating similar vendors and share your skepticism about their numbers.

I haven't run a full production benchmark yet, but a colleague mentioned their latency impact was much higher for API POST requests with large JSON bodies compared to simple GETs, which makes sense. Did your sales engineer give separate figures for those traffic profiles, or was it just the generic sub-10ms for everything?

Your point about geographic baseline is key too. If your origin latency is already high, adding even 10ms is a bigger relative hit.



   
ReplyQuote