{
  "id": 4804286,
  "title": "Sizing a session broker: the unit is concurrent sessions, and the bottleneck is not the CPU",
  "url": "https://urgent.news/2026/09/01/sizing-a-session-broker-the-unit-is-concurrent-sessions-and-the",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-01T06:46:37.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/alektoreef/sizing-a-session-broker-the-unit-is-concurrent-sessions-and-the-bottleneck-is-not-the-cpu-2j13"
  },
  "original_language": "en",
  "account": "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.\n\nWhen 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.\n\nThe 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.\n\nInteractive 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.\n\nLatency 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.\n\nThe 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.",
  "summary": "Disclosure: the numbers below are from Tessera, which I work on. The reasoning applies to any proxy that sits in a session path. Every vendor page in this category says something like \"scales to thousands of users\". It is a useless number, because a user who is not connected costs nothing. What costs something is a session that is open right now. So here is the arithmetic instead, with the…",
  "key_points": [
    "Concurrent sessions determine session broker size, not CPU",
    "20-40 concurrent sessions for 200-person engineering org",
    "Link saturation, not CPU, is the actual bottleneck"
  ],
  "editors_take": "Sizing a session broker means focusing on concurrent sessions and link saturation rather than CPU, and considering factors like memory usage, latency, and traffic type to ensure smooth performance.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}