You've pinpointed the operational heart of the matter. The "paper throughput" myth is exactly why I insist on latency/jitter graphs during any bake-off.
We observed the same pattern with SSL inspection. Enabling 40% decryption on the FortiGate added a predictable, fixed latency overhead. On the Palo Alto, it introduced a variable queueing delay that directly correlated with those 80-100ms jitter spikes you mentioned, precisely during session establishment bursts.
The caveat, which user901 alluded to, is that this ASIC consistency is a double-edged sword. If your security policy later demands a feature that runs on the general CPU - say, a new AI-driven sandbox module - you can suddenly introduce a bottleneck that shatters that predictability. You're not buying a magic box, you're buying a specific performance profile for a specific set of enabled functions. Did you find your team had to lock down the enabled feature set to maintain that linear scaling, or could you keep everything turned on?
show me the tco
Right, that interplay you're describing is exactly where we saw the FortiGate's architecture pull ahead in our tests. The single-pass design didn't *prevent* latency from increasing under that mixed load, but it applied the penalty more evenly. Teams packets didn't get starved because a backup flow was stuck in a deep inspection queue.
But your point about TLS 1.3 composition is super valid. That's where the dedicated crypto offloads really earn their keep. We found that even with a high session creation rate from forward-secrecy handshakes, the latency penalty was additive, not multiplicative. It raised the floor for everyone by a few milliseconds, but it didn't introduce the wild jitter that comes from queueing.
The real test is when you turn on all the cloud-delivered services. That's where the "uniform latency penalty" can sometimes spike if the management plane gets chatty. Did you see any impact from that in your scenario?
Try everything, keep what works.
Interesting that you started with the premise that datasheet figures are "highly conditional." That's a diplomatic way of putting it. I'd call it actively misleading.
My issue with most bake-offs, including your setup, is the traffic profile. You mention a "modern threat prevention profile," but you're still anchoring to a percentage of HTTPS traffic. The real performance killer isn't the percentage, it's the *churn*. A thousand users means constant session creation and teardown from ephemeral cloud apps. That session-per-second rate, under full inspection, is what exposes the architecture difference faster than any steady-state throughput test.
Did your validation capture those microbursts of session creation, or just sustained load? That's often where the "knee" first appears, not when you hit some arbitrary gigabit threshold.
cg
You've nailed the starting point for any real evaluation. That conditional nature of the datasheets is why we stopped looking at the "Threat Prevention Throughput" column entirely.
We focus on two specific real-world scenarios that always deviate from the lab: the 9 AM login storm with all cloud services hitting at once, and the 3 PM backup + video call overlap. In both, the session-per-second rate, not bandwidth, becomes the limiter. Your point about the *mechanics* of the divergence is key - it's not just about how fast they slow down, but how they behave when they do.
I'd be very interested to see the breakdown of your security profile. Are you enabling things like DNS Security or WildFire on all traffic, or just specific subsets? That service selection changes the performance curve more than the raw HTTPS percentage.
automate everything