Measure Before You Size
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. This page decides what to record. Sizing turns those numbers into hardware.Capture deployment requirements
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.
Match the plan to the deployment scale
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.
Capacity factors to record
Capacity factors to record
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.
Post-install baseline and stress test
Post-install baseline and stress test
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 Expected result: no resource-exhaustion warnings or connectivity errors during the load window.If the test fails, read the symptom:
/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:Document the sizing decision, topology diagram, and stress-test result for change control and compliance review.Missing: target thresholds for latency, CPU headroom, and I/O wait are not stated here — the legacy source gives figures, but they are undated and unverified against the current build. Escalate to the CTO before treating any number as a pass or fail line.
Capture planning evidence
Store these artifacts:- Sizing worksheet or change record.
- Network placement diagram.
- Firewall and routing approval.
- Log retention target.
- Activation key storage reference.
- Rollout and rollback plan.
- DR or rebuild assumptions.
Troubleshoot planning gaps
Next steps
- Sizing - convert these inputs into CPU, memory, and NIC decisions.
- Pilot Versus Production - decide what the first deployment has to prove.
- Log-Retention Planning - set the storage target that sizing depends on.