Your benchmark methodology is sound, but to validate the "average increase over direct" figure, we need to see the underlying distribution. The mean is easily skewed by outliers, especially in a global test. Could you share the 95th percentile latency for each location alongside the average? That delta often tells the real story about user experience.
Also, for **TLS decryption performance under sustained load**, how did you model the load? A constant concurrent user pool, or did you simulate the diurnal pattern of your actual business? We found the engine behavior changed markedly during ramp-up periods, which a steady-state test misses.
Measure everything, trust only data
That's a really good point about the 95th percentile vs the average. We only looked at the averages in our initial report. I'll need to go back and pull that distribution data.
For the load modeling, we used a constant concurrent pool based on peak hour numbers. We didn't simulate the ramp up. You think that's a big blind spot?
You've set up a solid foundation for the discussion, and focusing on the SWG component first is the right call. A lot of the value in a migration like this shows up in the web gateway before you even get to the full CASB features.
I do want to echo what others are hinting at about your table. Posting just the average increase can be a bit misleading without the distribution. For a real comparison, we'll need to see that 95th percentile latency for each location next to the mean. That spread tells you more about consistent user experience than the central number.
On your fourth criteria, TLS decryption under load, could you clarify if you tested with a full production-like policy stack from the start, or a simpler baseline? That choice dramatically changes how you interpret the performance data.
Keep it civil, keep it real