Skip to main content

Size Against Peak, Not Average

Averages hide the burst that drops sessions. A node sized for the mean sails through the working day and fails between 09:00 and 11:00, when every browser tab, background application, and API client opens connections at once. Sizing from a user count alone produces a node that passes a demo and drops sessions at 09:30. The inputs that actually drive capacity — peak concurrency, inspection scope, and log volume — are measurable, and a short pilot measures them far more cheaply than a production rollback does.

Measure before you size

Record these inputs before choosing an installation path:
  • User count and expected concurrent users.
  • Peak web throughput and business-hour traffic patterns.
  • Expected HTTPS inspection scope.
  • Authentication source and group-policy requirements.
  • Log retention target and SIEM or reporting destination.
  • Availability target for internet egress.
  • Rollback method for client proxy settings and routing.
Use the first deployment as a measured pilot, not a blind production cutover. Size conservatively when HTTPS inspection, malware scanning, DLP, or detailed logging is enabled. These controls add security value, but they also increase CPU, memory, and disk-write demand — a node sized for plain forwarding will not carry the same user count once inspection is on.
Include these values in the sizing worksheet:
  • Concurrent users and concurrent connections during peak hours.
  • Expected inspected HTTPS percentage.
  • Malware scanning and DLP scope.
  • Average and peak bandwidth.
  • Cache usage expectations.
  • Log volume, reporting retention, and SIEM forwarding rate.
  • Support-bundle and packet-capture storage needed during incidents.

Validate prerequisites

Confirm:
  • Peak concurrent connections are measured or estimated, not assumed.
  • The HTTPS inspection scope is known — it changes CPU demand substantially.
  • The log retention target is agreed. Use Log-Retention Planning.
  • The candidate CPU supports AES-NI.

Read the sizing matrix

Size against peak concurrent connections, not average. NIC counts are minimums. See the bonding guidance below.
Assume 3 to 5 concurrent connections per active user at peak. Heavy SaaS or streaming environments reach 6 to 8.For example, 200 active users at 5 connections each is 1,000 concurrent connections, which maps to 8 cores and 16 GB above.Average session duration is typically 3 to 5 minutes, with peaks between 09:00 and 11:00 and between 14:00 and 16:00. Size for the peak window, not the daily mean.Above 4,000 concurrent connections, assign multiple WAN IP addresses to avoid outbound NAT pool exhaustion, and evaluate Proxy Clustering rather than a single larger node.

Require AES-NI

A CPU without AES-NI decrypts SSL 3 to 5 times slower, which produces latency spikes and dropped connections under HTTPS inspection load. Verify before committing to hardware:
Expected result: the flags line includes aes. An empty result means this CPU should not carry an inspecting proxy.

Choose the storage media

SafeSquid writes continuously for session logging, behavioural analysis, and threat detection. Storage media choice is a correctness concern, not only a performance one: when writes fall behind, log entries are delayed or missed, and the audit trail you depend on during an incident has holes in it. Use NVMe SSDs — M.2 or PCIe-attached — for these paths: SATA-connected SSDs have substantially lower write throughput than PCIe-attached NVMe and cause logging delays and missed entries under load. Verify the attachment type, not just the label “SSD”.
Use one interface for simple pilot deployments unless a separate management or high-availability design has been approved. For production networks with bonded interfaces, confirm switch-side LACP configuration, VLAN tagging, MTU, gateway selection, and failover behavior before routing users.Evidence should include interface names, MAC addresses, bond mode, switch ports, VLAN IDs, and the owner of any routing or firewall policy that forwards traffic toward SafeSquid.Link Aggregation Control Protocol (LACP) bonding combines physical interfaces into one logical link for bandwidth and redundancy. Without bonding, a single failed NIC can take the proxy offline entirely.Match the bonding layout to the number of physical ports available:Bonding is configured on both the host and the switch. A host-side bond without matching switch-side configuration fails open or drops frames, so treat the switch change as part of the same change record.
Pre-install connectivity checks prove the host can reach what it needs. They do not prove the host can carry the load you sized it for. Run a baseline after installation, before production users arrive, so you have a known-good reference to compare against during a later incident.Establish a light-load baseline. Record session latency from /var/log/safesquid/extended.log, CPU utilisation, and disk I/O wait while a small number of clients browse. Keep the figures with the deployment record — the absolute values matter less than having a comparison point.Stress test to the sizing target. Simulate the peak concurrent connections you sized for, using a load generator configured for HTTP proxy mode such as JMeter, or multiple concurrent browser sessions driven by Selenium. Confirm session counts hold without dropped connections.Check logs during and after the run:
Expected result: no resource-exhaustion warnings or connectivity errors during the load window.If the test fails, read the symptom:Document the sizing decision, topology diagram, and stress-test result for change control and compliance review.

Capture sizing evidence

Store these artifacts with the deployment record:
  • The peak concurrent-connection figure and how it was measured or estimated.
  • The matrix row chosen, and the inspection scope it assumes.
  • grep aes /proc/cpuinfo output for the target CPU.
  • Storage attachment type for each of the three write paths.
  • Bond mode, switch ports, and VLAN IDs where bonding is used.
  • Network placement diagram and firewall/routing approval.
  • Rollout and rollback plan, and DR or rebuild assumptions.

Troubleshoot sizing failures

Next steps