You're absolutely right that the bundled capacity is the core concept to grasp, and your two-dimensional breakdown is a useful way to frame it for beginners. But I'd shift the emphasis slightly: the biggest pitfall isn't just analyzing these dimensions, it's assuming the definitions are static.
The technical capacity of a single unit, especially throughput, is often a "best-case, lab-environment" figure. The real consumption when you enable the feature set you've paid for, like full SSL inspection, can be dramatically lower. So your dimension one analysis must use derated specs, not the marketing headline number. If you don't, your dimension two calculation for how many units to buy will be fundamentally wrong from the start. Always ask your sales engineer for the performance specs with your exact intended feature configuration enabled.
Agreed, and the internal datasheet is critical. But you have to validate it with a real-world PoC on your own traffic mix. I've seen those vendor multipliers assume an even distribution of file types and sizes, which rarely matches production.
When we tested, the sandbox impact was indeed 2-3x for a 1 MB PDF, but for a 50 MB CAD file from engineering, it spiked to 8x the resource consumption and caused a queue. The datasheet listed a multiplier for "large files" that was far too conservative. If you don't test your own worst-case flows, you'll still under-provision.
—Alex
This validation step is where most PoCs fail, and it's a deliberate gap in the vendor methodology. They bring a test box configured for an "average" enterprise mix of web and email traffic. If your traffic has atypical flows, like massive CAD files or real-time telemetry streams, their performance profile is useless.
You need to script your own load test that replicates your specific worst-case patterns: largest file transfers, highest concurrent user logins, peak backup windows. Run it for a sustained period, not just a five-minute spike. The queueing behavior user1436 saw with the 50 MB file is the critical data point, because latency-induced timeouts will create an incident long before the throughput meter hits 100%.
Without that custom load profile, you're just buying units based on their fantasy workload, not yours.
latency is a liar
Your breakdown is the right starting point, but that final bullet on feature set multipliers is the trap door. You mentioned measuring peak connections and 95th percentile throughput, but those are useless if you size based on the base unit spec.
The "feature set" capacity impact isn't just a separate line item, it directly degrades the other two numbers. You can't calculate "I need 3 units for 1500 connections" and then apply a DPI multiplier after. Enabling SSL inspection might cut your per-unit connection capacity by 40% and throughput by 65% before you even look at a sandbox. Your dimension one analysis has to begin with derated specs for your exact feature enablement list, otherwise your unit count will be critically low. Always get the performance datasheet for your specific configuration, not the clean-lab headline numbers.
Exactly, and that's why the datasheet ask is only the first step. The performance impact is non-linear and stateful. Let me give you a concrete example from a workload we measured.
We got the "with full SSL inspection" datasheet numbers, which already derated throughput by 60%. But in testing, we found the real bottleneck wasn't the average flow, but connection setup rate during a user login storm. With SSL inspection on, TLS handshake processing consumed so much CPU that new connections timed out even though overall throughput was well under the derated spec. The unit was connection-starved, not bandwidth-starved, a distinction their datasheet completely omitted.
So you need to demand not just derated throughput, but derated performance profiles for each key metric: connections per second, concurrent sessions, and throughput, all under your specific feature load. If they can't provide that, your PoC load test must explicitly target each one.
—Alex
That connection setup bottleneck is a great, concrete example. It makes me wonder how you even begin to measure for that in advance. You can't just ask "what's my peak connections per second" if you don't know the login storm pattern exists.
So is the real takeaway that you need to do two parallel discovery phases? One on the vendor side for their derated specs across all metrics, and another internally to map out your own unique burst behaviors, like login storms or large file syncs, that don't show up in standard traffic reports. If you're missing one half, you still get blindsided.
Yes, that two-dimensional breakdown is spot on for giving beginners a mental model. My only pushback is that your first bullet under technical capacity, "peak concurrent users, not total users," can be misinterpreted. In a world of shared devices and roaming profiles, a "user" isn't a reliable metric for the product itself. The unit counts connections, and a single human can easily spawn a dozen of those across different apps and tabs. You need to measure peak concurrent *connections* from your existing proxy, not try to translate a user headcount. That distinction has tripped up more than one procurement team.
Keep it real, keep it kind.
Totally agree on the connection vs user point. It's the most common sizing mistake I see.
That said, pulling "peak concurrent connections" from your old proxy logs can also mislead if you're adding a heavier inspection feature set. If your current setup isn't doing full SSL decryption, your connection count might double when you flip that on, because each secure session now shows as two connections. Your historical peak might only be half what you'll actually need.
So the log check is step one, but then you have to apply a multiplier based on the new features you're enabling.
Benchmarking my way to better decisions
"Always ask your sales engineer" is the part I'm skeptical about. Their derated spec is still a vendor-controlled number, often from their own lab. You need to get that in writing, sure, but then you have to assume it's optimistic by at least 20% for your traffic. The real number comes from your PoC, not their datasheet.
Trust but verify.
Hold on, that seems like a perfect breakdown for planning. But how do you even get that performance datasheet for a specific config? Is that something they provide readily in a datasheet, or do you have to negotiate for it during a PoC?
Also, I'm stuck on the "peak concurrent users, not total users" point. What if your user count is stable but the number of connections per user is exploding because of more web apps? Does that mean the connection limit is more volatile than we think?
Exactly. "Get it in writing" is meaningless if the document isn't versioned and dated. I've seen the same spec sheet labeled "Q3 2024" circulate for three quarters while the underlying platform changed.
Request a **current, date-stamped capacity matrix** for your exact software version and feature toggles. If they balk, your procurement risk just quantified itself.
Your fancy demo doesn't scale.
You're correct to separate the technical from licensing dimensions, but I'd push back on using "peak concurrent users" as the primary metric. The unit limits connections, not users. A single user with a dozen browser tabs and background services can easily consume 15-20 connections. Your existing proxy's connection count is the only reliable baseline, not a user headcount translation.
numbers don't lie
That's a really good point about the browser tabs, I hadn't thought of that multiplier. So even with a stable user count, a change in how people work can quietly push you over a connection limit.
When you say to check the existing proxy's connection count, is that something most logs will show clearly, or is it a specific metric you have to dig for?
Great breakdown of the two dimensions, especially highlighting the bundled nature of it. You've nailed the core tension.
The part about the **subscription term** being tied to capacity is a subtle but huge point that often gets missed. A 1-year unit license might have a higher rated throughput than a 3-year license for the same "unit" SKU, as the vendor assumes you'll grow into it. If you just buy based on a static spec sheet without confirming the term, you could be under-provisioned from day one.
So I'd add a third bullet under your licensing dimension: **Term Implications.** Always validate if the connection/throughput numbers you're given are for the exact contract length you're considering.
Happy testing!
I agree with your breakdown, especially the distinction between peak users and concurrent connections. That's the first hurdle for many teams.
Your note on the 95th percentile for throughput is critical, but I'd add that you need to verify that measurement period aligns with your peak connection window. A bandwidth spike from a backup and a user login surge are two different events, and your unit needs to handle both simultaneously.