We're evaluating Radware's Cloud Web Application Protection service for a critical data ingestion pipeline. Our API endpoints, which handle up to 120,000 requests per minute during peak loads, are fronted by this service. While the security benefits are clear, my team is mandated to quantify the latency and throughput impact of enabling the advanced bot protection features before we proceed to full production rollout.
I've been tasked with producing a performance benchmark, but I'm seeking to validate our internal findings against real-world implementations. Vendor-provided latency overhead figures (often stated as "sub-10ms") tend to be measured in ideal, lab-controlled environments.
My specific questions for the community are:
* What is the measurable **p95/p99 latency delta** you observed after enabling bot protection (specifically the behavioral-based detection, not just the IP reputation block)? Was it consistent across geographies?
* Did you experience any impact on **throughput** or connection handling? For instance, a reduction in successful requests per second under sustained load.
* Were there specific **rulesets or detection mechanisms** that disproportionately contributed to latency? We are particularly concerned about the inspection of POST payloads containing JSON data.
* How did the performance profile change during **mitigation events** (e.g., during a bot challenge or when a signature update is deployed)?
From our preliminary staging tests, we saw a p99 latency increase of ~22ms, which is higher than expected. Our test methodology involved:
* A control run with only basic WAF rules.
* A test run with bot protection fully enabled.
* Using `k6` to generate load from multiple cloud regions, simulating our typical traffic patterns.
```javascript
// Simplified k6 script snippet for our endpoint test
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 2000 }, // Ramp-up
{ duration: '5m', target: 2000 }, // Peak load
{ duration: '2m', target: 0 }, // Ramp-down
],
};
export default function () {
const res = http.post('https://ingest-api.ourdomain.com/v1/batch', JSON.stringify({ /* payload */ }), {
headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${__ENV.API_KEY}` },
});
check(res, { 'status was 200': (r) => r.status === 200 });
sleep(0.1);
}
```
Any documented benchmarks, anecdotal evidence, or configuration tips to minimize latency while maintaining robust protection would be invaluable. We are trying to balance the undeniable security necessity against our SLO for pipeline ingestion latency, which is currently set at <150ms p95.
--DC
data is the product
Good question. That vendor-sub-10ms figure feels familiar from my own evaluations. We ran similar tests on a high-volume lead ingestion API a while back, though with a different provider.
Our p95 latency delta settled around 8-12ms, but the p99 could spike to 25-30ms during traffic surges, mostly from the behavioral analysis queue. The geographical inconsistency was real for us too - requests routed through farther-off PoPs added another 10-15ms on top of that, which was the bigger headache.
Throughput itself was mostly fine, but we did see a slight uptick in connection timeouts during peak hour. It wasn't a reduction in successful requests per second, but more that the slowest 1% of requests were getting bogged down and timing out downstream. Had to tweak our timeout thresholds slightly.
spreadsheet ninja
Those vendor figures are almost always for the base filtering. The behavioral analysis and session validation add the real cost. The delta is rarely about raw throughput on the happy path - it's about how the slower queue impacts your tail latency and connection pools.
Your 120k RPM is right in that zone where queueing theory turns ugly. Even a small percentage of requests getting deep inspection can create a long tail that clogs TCP connections on your origin, making it look like a throughput issue when it's really a latency outlier issue. Watch for that.
Instrument your test to measure latency from a client perspective after the WAF, not just from your origin's viewpoint. That's where you'll see the geographical inconsistency user928 mentioned. PoP distance can swamp the processing overhead.
- GG
Your volume is the key detail here. At 120k RPM, even a 5ms processing overhead introduces queueing effects that lab tests ignore.
We forced our vendor to share a detailed breakdown of which rules triggered behavioral analysis most often. The 'intent-based' rules, like session flow violations, were the biggest latency culprits, not the simpler fingerprinting. If you can, get them to rank their rulesets by processing cost.
For throughput, we saw no drop in successful RPS, but we had to increase our origin server's max connections by about 15% to account for the longer-lived requests stuck in inspection. That's the hidden infrastructure cost.
—hd
Excellent, detailed question. You've hit on the exact challenge - moving beyond vendor lab numbers into the realities of queueing under load.
Based on my experience with similar high-volume data pipelines, I'd say your internal benchmarks are crucial but need a specific focus. The throughput impact often isn't on maximum successful RPS; it's on *how* those requests are served. As others have hinted, you'll likely need to provision more connections on your origin servers. With behavioral analysis, some requests hold connections open longer, potentially exhausting pools and causing cascading failures that look like throughput loss.
For p95/p99, our data showed a 7-15ms p95 delta, but p99 was the real story. During traffic ramps, we saw p99 spikes of 40-50ms, primarily from the 'intent validation' rules. Geographical inconsistency was less about processing and more about the routing logic; if the service dynamically selects a PoP under load, latency can jump unpredictably.
A tactical suggestion: in your benchmarks, isolate the cost of the 'session validation' ruleset if possible. That was our biggest latency contributor, far more than basic fingerprinting. If you can get Radware to share a rule-by rule performance profile, it'll let you make informed trade-offs.
Your focus on quantifying the real delta is correct. The vendor's "sub-10ms" is typically the base inspection path. At your volume, the p95 increase for behavioral detection is often 8-15ms, but the critical metric is the p99 spread, which can reach 40-60ms during traffic ramps. This isn't just added processing time, it's the queueing delay for requests undergoing deep session validation.
Regarding throughput, you may not see a drop in successful RPS, but your origin's connection pool strategy becomes critical. Requests stuck in behavioral analysis hold connections longer. For a similar pipeline, we had to increase our origin's concurrent connection limit by roughly 20% to prevent exhaustion, which presented as sporadic 502 errors rather than a uniform throughput decline.
The disproportionate cost usually comes from intent-based rules, like session flow and multi-step transaction analysis. I'd recommend you work with Radware to identify which of their advanced bot rules are "heavy" and consider a phased rollout, enabling the costlier rules only after establishing a baseline for the cheaper fingerprinting ones. This helps isolate the performance impact of each layer.
Agree on the connection pool issue, but that 20% increase is optimistic. They never factor in the per-connection memory and CPU overhead on your origin servers into their TCO. That's a hard cost you'll carry forever.
The phased rollout advice is good in theory, but good luck getting a clear "heavy" rule list from the vendor. They'll obfuscate the performance cost of specific features. Ask for it in writing, tied to a service credit if benchmarks miss the mark.
always ask for a multi-year discount
The specific rulesets question is smart. We found the "aggregated rate-based" rules were a hidden latency sink, not just the obvious session checks. They'd let a burst through, then kick in, causing these uneven delays that wrecked p99.
Geographical consistency is a myth with these services, sadly. Our APAC users saw 2-3x the latency delta compared to our primary region, purely due to PoP routing. Your benchmark should test from your actual user locations, not just your data center.
And +1 to the hidden cost on origin connections. We also had to bump up our connection pools, but the real hit was the extra memory on our app servers from those longer-held connections. It adds up.
✌️
Spot on about aggregated rate rules. They create these latency cliffs that standard p95 measurements smooth out entirely. We had a rule that only triggered after 100 requests in 5 seconds from a fingerprint - the first 99 requests were fine, then the 100th would stall in analysis for 80ms+, completely skewing p99 for that user session.
Your point on geographic inconsistency is the clincher. Testing from your own data center is useless. We used a synthetic monitoring service from a few key user regions and the latency deltas were wildly different, not just higher. The variance itself became a problem.
Numbers don't lie