I've been evaluating various SASE/SSE platforms for a consolidated observability pipeline, and a key requirement is minimal latency impact from TLS inspection. We're a Datadog shop, so I instrumented a simple test to measure the performance delta introduced by FortiSASE's TLS 1.3 decryption.
My baseline is a direct connection from a test client (t3.xlarge in us-east-1) to a simple API endpoint (also in us-east-1). With TLS 1.3 and no inspection, I'm seeing a consistent median RTT of 28ms over 10k HTTPS requests. The same test, routed through a configured FortiSASE tunnel with TLS 1.3 inspection enabled, yields a median RTT of 61ms. That's a 118% increase in latency.
The more concerning metric is the 95th percentile (p95). The baseline p95 is 34ms. Through FortiSASE with inspection, it jumps to 142ms. This suggests significant variability and potential for request queuing under load.
For comparison, I've run similar tests with other cloud SSE providers (which I won't name here to avoid a vendor debate) and observed a typical latency overhead of 15-25ms at the median. The FortiSASE result seems notably higher. My test command is below:
```bash
# Using a simple tool to capture connect, TTFB, and total time
./h2load -n 10000 -c 100 https://api-test.example.com/endpoint
```
Configuration details: FortiSASE was set up with default inspection profiles, using a Fortigate VM as the inspection engine. The tunnel was an IPsec VPN. The test payload was a 2KB JSON response.
Has anyone else conducted similar performance benchmarking, specifically for TLS 1.3? I'm curious if my 33ms median overhead aligns with your findings, or if there are tuning parameters I've missed that could reduce this penalty. My primary concern is the impact on user-experience monitoring for external-facing applications.
null
Your numbers, particularly the p95 jump from 34ms to 142ms, are a red flag. The median overhead you're seeing aligns with what I'd expect for a full proxy architecture performing TLS termination and re-encryption, but that tail latency suggests a bottleneck, likely in the crypto operations or session resumption handling.
Have you checked if your test is forcing a full TLS handshake for every request? A 10k-request run with connection reuse should minimize that, but if the inspection proxy is not properly caching session tickets or is using a less optimized cipher suite, it could explain the p95 variance. You might also be measuring the control plane distance if your tunnel is being hairpinned to a centralized inspection node instead of a local PoP.
For a fair comparison, you'd need to instrument the client to log TLS handshake times separately from request/response. That would isolate whether the delta is in the connection setup or the data path.
--perf
Your methodology is sound, and focusing on the p95 is the right call; the median delta, while high, is manageable for many use cases, but that tail latency is where user experience disintegrates. The 142ms p95 indicates a resource constraint or architectural bottleneck that isn't exposed by median values.
I'd be curious if you could isolate the inspection plane's location. Your test client and endpoint are in the same region, but if your FortiSASE tunnel terminates at a geographically distant inspection node, you're adding physical latency on top of processing overhead. Could you run a traceroute from your test instance through the tunnel to see the actual egress point? Many SASE providers use a regional PoP, but some configurations default to a central hub.
Also, check the cipher suite negotiated after inspection. The proxy might be defaulting to a different, slower suite than your client's optimal choice, which would compound the latency. Your 118% median increase already suggests a full proxy break-and-inspect, but the cipher could make it worse.
Data is the new oil – but only if refined
The cipher suite point raised by user747 is critical. Many inspection proxies default to a more conservative, CPU-intensive suite like TLS_AES_128_GCM_SHA256, while your baseline might be using TLS_AES_256_GCM_SHA384 or CHACHA20_POLY1305, which can have different performance characteristics on modern hardware. Could you share the output of `openssl s_client` for both the baseline and the inspected connection? The negotiated cipher and whether session resumption is actually working will tell us a lot.
Beyond that, a 118% median increase suggests the inspection plane might be undersized for the traffic profile or not using hardware crypto acceleration. You're seeing the classic trade-off of a full MITM proxy; every byte gets decrypted, inspected, and re-encrypted, which is fundamentally a serial process. For an observability pipeline, this added jitter could skew your metrics. Have you tested the impact on sustained throughput, not just latency? Sometimes the latency per request is acceptable until you hit a concurrency limit where the proxy's queue depth explodes, causing that p95 spike.
infrastructure is code
That's a really solid set of baseline numbers, user443. The p95 jump is definitely the part that stands out, and it's good you're tracking it. A 118% median increase is one thing, but that tail latency spiking to 142ms is where real-world impact starts to show up.
One thing I noticed in your post is the test command seems to have been cut off. Could you share the full command and the tool you used? Knowing whether you're reusing connections or forcing fresh handshakes each time would help narrow down if the bottleneck is in session resumption or just raw crypto throughput. Also, any chance you know which FortiSASE PoP is handling the inspection? If your tunnel is landing in a different region than us-east-1, that could explain part of the variance.
I'd be curious to hear if you see similar behavior when you profile the same test with a smaller payload or a different cipher suite. Sometimes the inspection proxy's choice of cipher can add more overhead than the actual decryption logic.
Stay constructive