Fortinet vs Palo Alto for a 1000-user enterprise: real-world throughput comparison

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?

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?

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.

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.

That's a great point about focusing on those two daily scenarios. They map almost exactly to our complaints before we started our evaluation.

We're testing with DNS security enabled for all traffic, which has added a surprising amount of overhead. The datasheets just don't talk about that. WildFire we've set to only trigger on executables from unknown external sources, so the volume is much lower. It feels like the decision of what to turn on everywhere versus selectively is going to be the real performance driver, more than the box itself.

Your mention of session-per-second as the limiter hits home. In our early 9 AM storm tests, we saw the Palo Alto's management plane CPU spike much higher during that initial burst, which seemed to delay policy lookups for a few seconds. Does that match what you saw?

That's a great question. In our test with a FortiGate 600F under a mixed workload, the baseline latency hovered around 1.2ms. At the performance knee, which we defined as the point where 99th percentile latency exceeded 10ms, the average had climbed to about 8ms. The crucial detail was that the 99th percentile figure was 12ms, so the experience was consistently degraded, not spiky.

The Palo Alto on the same test had a similar 1.5ms baseline, but its knee was defined by a much wider spread. The average latency at its drop point was 5ms, which looks better on paper, but the 99th percentile was 32ms. That's where users would start noticing calls breaking up, even though the dashboard might not show an "overload" condition. Does your team track that 99th percentile metric during validation, or do you find average latency is the primary focus?

Oh, that 99th percentile vs average detail is exactly the kind of thing I wouldn't have thought to look for, but it makes total sense. A consistent 12ms sounds way better for our call quality than a wildly spiking 32ms, even if the average looks good.

A quick follow-up, if you don't mind: when you measure that 99th percentile, are you running those tests over hours, or is it more of a short burst during the "login storm" scenario people mentioned? I'm wondering if the difference gets even bigger over longer periods.

That pricing observation lines up exactly with what we've seen in the community over the last year or so. The > $150k for a Palo Alto 3-year bundle is a hard pill for a lot of orgs to swallow.

I'd add that while the support-lapse flexibility is real, I've seen teams get bitten by running FortiGates without updates for too long. The operational risk of missing critical vuln patches eventually forces a renewal anyway, so the "savings" can be a bit of a mirage if you're taking security seriously. It's a cash flow relief, not a long-term cost avoidance.

Your point about the single-pass architecture is the core of it, though. That consistency under load usually matters more for user experience than the raw throughput number.