Sizing a session broker: the unit is concurrent sessions, and the bottleneck is not the CPU

The unit that determines the size of a session broker is concurrent sessions, not the CPU. The planning rule is that a normal working day sees 10-20% of a team connected at once. For a 200-person engineering organization, that translates to 20-40 concurrent sessions, not a size that requires a cluster. A proxied session mainly consists of buffers, with about 320 KB per session.

For 200 concurrent sessions, this amounts to approximately 94 MB of live data. However, this is not what the resident memory will show, as Go does not release memory to the operating system promptly and the collector allows the heap to grow to roughly twice the live set before collecting. Thus, the resident memory settles at about double the initial calculation.

When sizing a Go service, it is crucial to consider the memory usage beyond the arithmetic calculation, as Go does not hand memory back promptly. The Helm chart typically ships with requests of 256Mi and limits of 1Gi, which corresponds to the middle row in the provided table.

The CPU is almost never the limiting factor, as encryption with AES-NI is performed in hardware on modern CPUs. One vCPU can handle 50 concurrent sessions, and four vCPUs can handle 200-plus. The exceptions are sustained file transfer and RDP, which hit different limits first. The actual bottleneck is the link saturation, with interactive only workloads saturating at 100 Mbit/s, and heavy transfers or RDP requiring 1 Gbit/s or even 10 Gbit/s.

Interactive traffic is negligible, with keystrokes and screen output being a few KB/s per session. RDP, however, requires significantly more bandwidth, with one session running 0.5 to 5 Mbit/s, and twenty concurrent RDP sessions demanding 100-200 Mbit/s through the controller. If RDP is a significant part of your usage, size the link for RDP sessions alone, treating everything else as rounding error.

Latency is the number people complain about, but it is often overlooked when sizing a session broker. The double hop adds round-trip time on every keystroke echo, causing users to perceive the tool as "laggy." To mitigate this, put the controller in the same datacenter as the targets. If you have targets in multiple regions, consider using multiple controllers instead of one highly connected controller.

The overhead of the proxy itself is approximately 20%, which is a floor rather than an expectation. For real networks, this overhead adds its own cost, so it is essential to consider this when sizing a session broker. Bulk transfers, such as database dumps, backups, and CI artefacts, should be routed outside the session broker to avoid unnecessary overhead.

Session recordings apply only to terminal sessions, with recordings ranging from 1-5 MB per session-hour. RDP traffic does not generate recordings, as it carries the RDP protocol rather than a terminal stream.