Hi everyone, I’ve been tasked with evaluating our new FortiGate 600E for a data pipeline project. Since we move a lot of sensor data in near-real-time, even small latency spikes can cause queue backups. I wanted to see the exact cost of enabling the full threat inspection suite.
I set up a simple test: a continuous ping (ICMP) from an internal application server to a cloud service endpoint, first with all UTM features off, then with everything on (AV, IPS, App Control, Web Filter). Traffic profile is mostly HTTPS/SSL-inspected and some custom TCP ports.
Here's what I found over a 24-hour average:
* **Baseline (no inspection):** 5.2ms
* **With full threat inspection:** 7.4ms
* **Delta:** ~2.2ms added latency on average
The max spike I saw was around 8ms under heavy load, but the average seems pretty consistent. This is on a 600E with firmware 7.2, and it's mostly handling east-west traffic between our analytics VLANs.
I'm actually relieved it's this low? Some blogs had me worried it would be much higher. But I'm still new to this, so I have a couple questions for those with more experience:
* Does this ~2ms average align with what you've seen in production?
* Are there specific inspection profiles or features that are known latency hogs that I should maybe tune differently? I just used the default "strict" profiles.
* For a data pipeline where the traffic is 90% internal service-to-service (like, from our Spark clusters to the database), is it overkill to have everything on? I'm thinking of maybe creating a separate policy for the analytics subnets.
Attached a screenshot of the latency graph from our monitoring tool. The bump around 02:00 is when I flipped the policy on. Grateful for any insights!
null
Your 2.2ms average delta is well within the expected range for the 600E with that firmware, especially considering you're inspecting SSL traffic. That decryption overhead is the main contributor. I've observed similar figures in latency-sensitive financial data pipelines, though the impact becomes more pronounced at higher throughputs where session table lookups and signature matching start to contend for CPU cycles.
The one caveat I'd add is that ICMP/ping is a useful baseline, but it doesn't capture the full picture for your data pipeline. The inspection latency for established, high-throughput TCP streams can be different than for individual ICMP packets. You might see slightly higher per-packet latency but better overall session throughput, or vice versa, depending on the traffic profile.
Have you run the same test with a simple TCP-based probe, like sending a small payload over a custom port you've mentioned, to compare? Also, was the 8ms spike correlated with a scheduled signature update or a peak in concurrent sessions? That's often where the variability lies.
Data over dogma
Your average delta looks consistent with what I've seen on similar hardware. The relief you're feeling is valid, that's a reasonable trade-off for the security posture.
One thing to consider is how you're measuring. As user759 hinted, using ICMP for your baseline might not reflect the true application latency for those SSL-inspected streams. The handshake and packet reassembly overhead in a real data transfer could shift those numbers, sometimes for the better. You might find the per-session impact is smoother than the per-packet ping test suggests.
Have you looked at the session table statistics during your tests? A high rate of new sessions per second, which is common with sensor data, can sometimes add more variable latency than the inspection itself. It's worth checking if your max spikes correlate with session setup rates.
Review first, buy later.