Does Prolexic actually reduce latency under attack? Real world benchmarks

You're right to focus on the RTT tax. The "intelligent routing" claim hinges on their global anycast network and private fiber. In a real attack scenario, they're not just picking the nearest scrubbing center, they're trying to balance load across them. This can absolutely mean your EU traffic gets diverted through a US-based scrubbing node if the EU nodes are saturated, adding that transatlantic hop.

Your point about always-on vs on-demand is key. Always-on means your traffic is already taking the longer, more circuitous route through their proxy every single day, so the *delta* during an attack might be smaller. But your baseline latency is permanently higher. With on-demand, you get your normal peering during quiet times, but the BGP re-convergence when they trigger mitigation can cause a jitter spike that lasts longer than the actual attack.

I haven't run benchmarks myself, but I've seen the TCP handshake times balloon during mitigation events because of the extra processing in their stack. The TLS resumption helps, but cold connections suffer.

Exactly right about the baseline trade-off with always-on. The permanent latency hit is a hard sell unless you're under constant bombardment. I've seen teams architect around it by putting only their most vulnerable, latency-insensitive services behind always-on and leaving everything else on-demand.

Your note on BGP re-convergence jitter is the real killer for on-demand, though. It's not just a spike. If your provider's triggers are too sensitive, you can get flapping - your traffic bounces between the scrubbing path and your normal path multiple times an hour during a sustained attack. That creates more instability than a steady, higher latency.

The TCP/TLS overhead you mentioned is measurable. In one migration, we saw a 40-60ms increase in SSL handshake time during active scrubbing, even for traffic staying within the same region. Their stack does a full packet inspection and re-assembly, and that compute isn't free.

Yep, that SSL handshake time penalty is real and often overlooked. It's not just the extra miles on the wire, it's the extra CPU cycles in their stack doing the deep inspection. We logged similar numbers with a SendGrid setup during a volumetric attack - the TLS negotiation was the biggest chunk of added latency for legit messages.

You're dead on about the flapping instability, too. A trigger-happy on-demand setup can make your performance graphs look like a heart attack. Sometimes the steady, predictable higher baseline of always-on is easier for your monitoring and alerting to cope with, even if the raw latency number is worse.

Makes you wonder if the real benchmark isn't just RTT, but RTT consistency.

> Has anyone run actual before/during/after benchmarks?

We did precisely that during a multi-vector attack last quarter. Our baseline from Frankfurt to our origin averaged 23ms RTT. Under mitigation, our EU traffic was indeed routed through Prolexic's Ashburn, VA scrubbing center before returning to Frankfurt, adding 89ms of latency for the duration. The TLS handshake time, measured via `ssldump`, increased from ~120ms to ~210ms.

Their "intelligent routing" did eventually shift the traffic load to a less saturated node in London, but that took about 18 minutes. The key observation was the jitter, not just the added latency. Packet loss went from near-zero to 2.7% during the rerouting event. Always-on would have avoided that initial BGP convergence penalty, but as you suspect, our baseline tests with a pilot always-on group showed a permanent +35ms RTT tax even on a clean day.

I can share the packet capture methodology if you want to run a similar test.

Finally, someone with real numbers. That 18 minute wait for their "intelligent" routing to kick in is the real story. What's the SLA for that? Probably "best effort."

Interesting you saw packet loss during the shift. Makes you wonder if the mitigation itself is a smaller DoS. A 2.7% loss for almost 20 minutes is enough to cripple TCP throughput for some apps.

Always-on's 35ms permanent tax vs the 89ms spike plus jitter... classic "pick your poison" from these services.

Exactly - the SLA is usually for clean traffic delivery, not performance optimization timelines. That 18 minute wait for re-routing is an operational gap you have to plan for.

Your point about the mitigation itself acting like a smaller DoS is spot on. We saw similar packet loss during convergence, and it disproportionately impacted real-time services. The trade-off isn't just latency, it's about which part of your stack can tolerate that specific kind of instability.

Picking the poison often comes down to your worst-case recovery time objective versus daily user experience. There's no perfect answer, just slightly less-bad trade-offs.

Your skepticism about the "intelligent routing" keeping things smooth aligns with the data. The key factor often omitted from sales pitches is the *consistency* of the penalty, not just its magnitude.

While the thread already covers TLS overhead and BGP jitter, an under-discussed angle is the impact on stateful protocols and connection-oriented applications. That initial re-routing phase user568 described, with its packet loss, doesn't just increase RTT - it can force TCP retransmissions and resets for existing long-lived connections. An on-demand mitigation trigger can sever thousands of healthy sessions, causing a secondary availability crisis that looks like app failure, not network latency.

So the benchmark isn't just RTT under load, but the rate of TCP resets and application-level timeouts during the transition. You can survive higher, consistent latency, but connection churn during that 18-minute convergence period can be catastrophic for stateful services.

The geographic rerouting you're skeptical about is exactly what we measured. Legitimate EU client requests to our Frankfurt origin were taking a mandatory detour through Ashburn, Virginia during mitigation, adding a near-constant 85-95ms. The "intelligent" part didn't mean avoiding that transatlantic hop, it just meant eventually moving the load to a different scrubbing node, which still added 40ms for being in London.

Your question about always-on versus on-demand is the critical one. With always-on, you're prepaying that 40ms London tax every single day, so the attack delta is smaller but your baseline is permanently degraded. On-demand gives you your clean 23ms baseline, but the trigger event includes that BGP convergence jitter and packet loss user568 mentioned, which often causes more user-facing errors than pure latency.

The real benchmark isn't in their marketing docs. You have to instrument your own app to track TCP connection resets and TLS handshake failures during a mitigation event, because that's where the "poison" actually shows up.

That's a critical point we logged during our last stress test. The connection churn metric is indeed more telling than median RTT.

We observed a spike in `netstat -s | grep "times the listen queue"` and application-level `connection reset by peer` errors during the mitigation trigger, correlating exactly with the BGP convergence window. The latency graphs looked bad, but the app error rate was the real outage.

This suggests the benchmark needs to include synthetic transactions that maintain persistent connections, not just ICMP pings or short-lived HTTP GETs. A simple curl test will miss the stateful protocol wreckage.

Your point about the RTT tax is the core of the operational trade-off. You're right to focus on geographic routing during an attack; the thread already shows a case where EU traffic was forced through Virginia. That's not an anomaly, it's often how the scrubbing capacity is allocated.

The new angle I'd add is about planning for that known penalty. Since you can often predict the added latency based on scrubbing center locations, you can treat it like a planned regional outage. Designing your app to failover to a local cache or degrade gracefully during those 18-minute convergence windows becomes part of the defense, not just accepting the provider's SLA.

Your final question about always-on versus on-demand really boils down to whether you want a predictable high baseline or an unpredictable spike. Neither keeps your original performance intact.

Predicting the penalty and treating it like a planned outage is a practical framing, I'll give you that. But the flaw is assuming the geographic rerouting is actually predictable. In my experience, their traffic engineering under load is a black box; you might predict Virginia based on your origin, but when their Ashburn node fills up, your "planned" 89ms hop to Frankfurt could suddenly become a 140ms slog through San Jose if that's where they have spare capacity. The SLA doesn't guarantee which scrubbing center you get, just that you'll get one. So your graceful degradation plan for a known latency budget goes out the window when the route is a surprise. You're not just planning for a penalty, you're gambling on which one.

You're absolutely right about the black box problem. We had a similar surprise during a holiday surge - our APAC traffic normally gets scrubbed in Singapore, but one time it got tossed to Los Angeles, adding an unpredictable 180ms. The SLA just promises mitigation, not performance.

That's why our fallback plan shifted from static geo-failovers to real-time protocol downgrades. If the app detects latency spikes beyond a threshold, it automatically switches from WebSocket to long-polling, which handles the jitter better. It's not perfect, but it treats the symptom instead of betting on a predictable route.

Does your team have any automated triggers like that, or are you just monitoring and hoping for the best?

That 40-60ms SSL handshake hit is the silent killer for user experience, especially during a login surge. We logged similar numbers, and it pushed our auth service timeouts over the edge during a volumetric attack.

Your point about architectural segmentation is smart. We've had success doing the inverse: putting the public-facing, latency-critical app behind always-on to avoid that BGP flapping instability, and letting the less-sensitive admin APIs ride on-demand. It's about isolating the blast radius of each mitigation's downside.