Session Scalability¶
This page separates capacity planning for Excalibur without AI from measured SSH session resource usage. Deployment minimums are listed in the Installation and Implementation Guide.
Hardware Sizing Without AI¶
The rounded engineering sizing rule is 3 GB RAM at idle, plus 1 vCPU and 2 GB RAM for every 50 concurrent active sessions. The 3 GB baseline is counted once for the reference deployment, not once per session or processing pod.
Concurrent active sessions means sessions running at the same time, not the number of registered or licensed users. A user running multiple simultaneous sessions contributes multiple sessions to this count.
This rule excludes Merlin AI. An AI GPU is not required when Merlin AI is not deployed; its hardware requirements are separate.
Calculation and Examples¶
Let N be the peak number of concurrent active sessions and B the number of groups of 50 sessions, rounded up. A vCPU is a virtual CPU.
B = ceil(N / 50)
Additional CPU capacity for sessions = B vCPUs
Application RAM estimate = 3 GB + (2 GB * B)
For example, 51 concurrent active sessions require two groups in this planning model.
| Concurrent Active Sessions | Additional vCPUs for Sessions | Application RAM Estimate, Including 3 GB Baseline |
|---|---|---|
| 50 | 1 | 5 GB |
| 100 | 2 | 7 GB |
| 250 | 5 | 13 GB |
| 500 | 10 | 23 GB |
| 1,000 | 20 | 43 GB |
These are calculated planning estimates, not benchmark results at each listed concurrency. The CPU column covers session processing in addition to the CPU needed by the idle platform; the sizing rule does not quantify that idle CPU requirement.
Relationship to Deployment Minimums¶
The 3 GB figure is an idle application footprint, not a minimum server RAM specification. The single-node requirements and high-availability requirements still apply.
Host operating-system and orchestration overhead, additional tenants or service replicas, and failover capacity are not quantified by this rule. Hardware sizing must satisfy both the deployment requirements and the concurrent-session workload; the table is not a complete host or HA cluster specification.
Basis of the Planning Rule¶
The engineering guidance reports approximately 60 concurrent sessions per vCPU, with a 2 GB memory limit per processing pod. The partner-facing planning rule rounds this down to 50 sessions per 1 vCPU and 2 GB RAM. A pod memory limit is an allocation ceiling, not a measurement of actual memory use.
The SSH results below describe a specific test workload. They are not a replacement for the planning budget and do not establish identical resource consumption for RDP or streamed web applications.
Test Environment¶
| Parameter | Value |
|---|---|
| Instance Type | Standard_D4s_v4 |
| CPU Model | Intel Xeon Platinum 8370C @ 2.80GHz |
| vCPU Count | 4 (allocatable: 3860m) |
| Memory | ~16 GB (allocatable: ~13.59 GiB) |
| Architecture | amd64 |
| OS Image | Ubuntu 22.04.5 LTS |
| Kernel Version | 5.15.0-1102-azure |
| Kubernetes Server Version | v1.33.6 |
SSH Sessions — Resource Consumption¶
As concurrent SSH session count increases, resource usage remains efficient and predictable:
| Concurrent Sessions | CPU Usage | Memory Usage | Network Bandwidth |
|---|---|---|---|
| 10 | Minimal (~0.1 cores total) | ~220 MiB | < 0.1 MiB/s |
| 50 | Low (~0.11 cores total) | ~1.1 GiB | < 0.16 MiB/s |
| 100 | Low (~0.14 cores total) | ~2.2 GiB | < 0.28 MiB/s |
| 150 | Moderate (~0.17 cores total) | ~3.3 GiB | < 0.36 MiB/s |
Key Takeaway
CPU and network bandwidth remain very low even at 150 concurrent sessions. Memory scales linearly at approximately 21 MiB per SSH session, which is the primary factor to consider when planning capacity.
SSH Tunnel Sessions
SSH Tunnel sessions do not significantly affect resource consumption. Their resource profile is comparable to — or lighter than — standard SSH sessions.
Horizontal Scaling¶
For deployments requiring more than 50 concurrent sessions, Excalibur supports horizontal scaling — adding additional processing replicas to distribute the workload.
In tested scenarios with 70 concurrent SSH sessions and 2 replicas, the memory load was effectively split across instances (each handling roughly half), confirming that horizontal scaling works linearly and predictably.
Session Recording Storage¶
PAM session recordings consume modest storage that grows with session count:
| Concurrent Sessions | SSH Recordings |
|---|---|
| 10 | ~0.8 MiB |
| 50 | ~2.9 MiB |
| 100 | ~5.7 MiB |
| 150 | ~9.0 MiB |
Storage Tip
Recording storage is minimal — even 150 concurrent sessions produce less than 10 MiB of recording data. Long-term storage planning should focus on total session volume over time rather than concurrent session count.