How do I properly size an SRX for a 500-user office with heavy web traffic?

Alright, let's cut through the vendor datasheet nonsense. You're asking about sizing for 500 users with "heavy web traffic," which is about as useful as saying "it moves data." I've seen SRX boxes sized by marketing math melt under real load. This isn't about user count; it's about flows per second, session table depth, and the specific pain points you're trying to solve.

First, forget the "500 users" figure. You need to gather real metrics, or make some brutally realistic assumptions. If you can't get this, you're already guessing. Answer these:

* **Sessions/Second:** This is the golden metric for SRX performance. Is this a call center where everyone's got 50+ browser tabs open to SaaS apps? That's a massive session churn. A conservative estimate for "heavy web" might be 0.5-1 new sessions per user per second at peak. So you could be looking at 250-500 sessions/sec. You need an SRX that can handle the *session establishment rate*.
* **Concurrent Sessions:** This defines your session table size. 500 users * 50-100 sessions each? That's 25k to 50k concurrent sessions. You need headroom. Don't max out the table.
* **Throughput:** Is "heavy web" just HTTP/HTTPS, or are you slinging large files? A 1 Gbps internet pipe doesn't need a 10 Gbps firewall, but you must account for inspection overhead. If you're enabling UTM (AV, Web Filtering, IPS), the throughput numbers on the datasheet get cut by 70% or more. That SRX345 "2.5 Gbps firewall throughput" might be 800 Mbps with IPS enabled. Get the "Threat Prevention" or "UTM" throughput number, not the "firewall" number.
* **Features:** Will you use IPS? IDP? AppQoS? SSL Proxy (decryption)? The last one is a performance killer. If you need to decrypt TLS 1.3, size your box as if you're handling double the traffic.

Based on vague "heavy web," I'd look at the mid-range SRX400 series. An SRX460 might be a comfortable starting point, but an SRX410 could suffice if your "heavy" is modest and you forgo deep SSL inspection. The SRX300 line might buckle under 500 sessions/sec. You need to look at the "Session Rate" column in the performance datasheet.

My generic, cynical advice:
1. Get a trial unit one model higher than you think you need.
2. Simulate load. Don't just ping it. Use a traffic generator to blast it with TCP sessions and HTTP requests. Here's a crude test idea using `httperf` from a server on one side to a target on the other (you'd need routing set up):

```bash
# Aim for your target session rate. This creates new TCP/HTTP sessions.
httperf --server 192.168.1.100 --port 80 --uri /test.html --num-conn 5000 --rate 300 --timeout 5
```
3. Monitor the hell out of it during the test:
* `show security monitoring performance` (look for drops)
* `show security flow session summary` (watch table count)
* `show system resources` (CPU/Memory)
* `show security flow statistics` (look for TCP rejects)

If you see session rate or CPU maxing out, you're under-sized. Also, factor in future growth and the 3-year TCO. The support costs on these things are where they really get you.

-- old salt