Skip to content

Session Scalability

Excalibur handles a significant number of concurrent PAM sessions while maintaining low resource overhead. Below is a summary of observed resource usage at various concurrency levels for SSH sessions.

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.