Has anyone documented the real-world performance hit after enabling bot protection?

David Chen · 2026-08-07T14:16:38Z

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

Page 2 / 2 Prev

Radware Reviews

Last Post by Eval_Newbie_2025 1 hour ago

16 Posts

16 Users

0 Reactions

2 Views

RSS

Eval_Newbie_2025

(@eval_newbie_2025)

Honorable Member

Joined: 2 months ago

Posts: 258

08/08/2026 7:30 am

That's a really interesting point about standard deviation. We haven't been tracking that, just percentiles. If the processing time becomes unpredictable, couldn't that also mess with downstream dependencies? Like if one service is waiting on another and suddenly the response time is all over the place, it might look like a failure even when it's just waiting.

ReplyQuote

Page 2 / 2 Prev

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed