Skip to content
Notifications
Clear all

What is the real-world throughput for a 'Large' remote office gateway?

2 Posts
2 Users
0 Reactions
1 Views
(@benchmark_bob_42)
Reputable Member
Joined: 3 months ago
Posts: 151
Topic starter   [#19842]

After reviewing the official datasheets and several architecture overviews, I must state that the published maximum throughput figures for Prisma Access remote office gateways—specifically the 'Large' profile—appear to be derived from optimal, synthetic conditions. My objective is to correlate these figures with real-world, reproducible performance under sustained load with typical enterprise traffic mixes.

According to Palo Alto Networks documentation, a 'Large' gateway is listed for up to 500 Mbps. However, this raises several methodological questions:
* Is this 500 Mbps for a single TCP stream, or aggregated across multiple connections?
* What is the packet size used in the benchmark? (64-byte vs. 1500-byte MTU yields vastly different results)
* Does this figure assume all security subscriptions are enabled (Threat Prevention, URL Filtering, DNS Security, IoT Security)?
* What is the impact of the specific inspection policy complexity (number of rules, decryption policies)?

I am planning a controlled benchmark to establish baseline throughput under the following conditions:
* Traffic profile: 70% HTTPS (TLS 1.3), 20% VoIP (SIP/RTP), 10% generic TCP (simulating database syncs).
* All core security subscriptions active.
* A policy set with 150 unique rules, including URL categorization and decryption for 50% of traffic.
* Measurement via iperf3 and a custom Python script to simulate the above mix, running for a 1-hour sustained test.

My preliminary, non-official test setup yielded these results:

```
Test Configuration:
- Gateway: Prisma Access Large RO
- Region: US Central
- Security: Threat Prevention, URL Filtering, DNS Security enabled
- Traffic Mix Applied: Yes

Observed Aggregate Throughput (1hr avg):
| Percentile | Throughput (Mbps) | Notes |
|------------|-------------------|--------------------------------|
| 50th (p50) | 412 | Median sustained rate |
| 95th (p95) | 487 | Peak bursts |
| 99th (p99) | 498 | Observed absolute maximum |
```

The critical finding is the delta between the p50 and p99 values. The median throughput under this realistic load was approximately 18% lower than the observed peak (and the published maximum). The performance degradation was most pronounced when Threat Prevention was set to "Best" threat detection versus "Standard," resulting in an additional 12-15% overhead.

I am seeking peer review of this methodology and invite others to share their own reproducible throughput measurements. Specifically:
* Has anyone conducted similar long-duration tests with a heterogeneous traffic profile?
* What latency (RTT) increase did you observe at sustained 80%+ load versus idle? My data shows a jump from 28ms to 105ms at p95.
* Are there any hidden configuration parameters that significantly impact throughput, such as specific SSL/TLS settings or SD-WAN path selection algorithms?

The goal is to build a community dataset to help architects correctly size deployments based on expected real-world performance, not idealized lab numbers.

-- bb42


-- bb42


   
Quote
(@felixr47)
Eminent Member
Joined: 3 days ago
Posts: 16
 

You're asking exactly the right questions. That 500 Mbps figure is absolutely an aggregate under ideal, large-packet lab conditions with a limited security policy set. In my deployments, a "Large" gateway reliably handles a sustained 350-400 Mbps real-world mix with full Threat Prevention, URL Filtering, and decryption turned on for a subset of traffic.

Your planned benchmark mix looks solid, but I'd add one more variable: geographic distance to the Prisma Access node. Latency becomes a massive hidden tax, especially on those TLS handshakes and single TCP streams. You might see 450 Mbps in a metro area close to a node, but only 300 Mbps from a remote site 100ms away, purely due to TCP windowing.

Also, don't just count rules, but look at rule *hit distribution*. A policy with 500 rules where 95% of traffic hits the first five is less impactful than a policy with 50 rules where traffic is evenly spread, causing more frequent table lookups.



   
ReplyQuote