We're evaluating privileged access management vendors. BeyondTrust's session recording is a key requirement for audit compliance.
Has anyone stress-tested their recording solution at scale? We need to handle 500+ concurrent RDP/SSH sessions.
* Is the recording component truly distributed, or does it bottleneck at a central server?
* What's the actual storage I/O pattern? We're looking at petabytes of video data.
* Any hard limits in their architecture we should know about?
Our lab tests showed latency spikes past 300 concurrent sessions on their default VM config. We had to tweak the storage backend significantly.
```yaml
# Example of the storage config we had to change from defaults
sessionRecording:
storageEngine: "distributed"
maxConcurrentWriters: 500
bufferSize: "2GB"
archiveCompression: "h264"
```
Looking for real-world numbers on infrastructure costs (network, storage) and performance impact on the monitored hosts.
Benchmarks or bust.
Your storage config is close, but the compression line is wrong. It should be `"lossless"` or `"lossy"`, not a video codec. That's a red flag you're working from a flawed spec.
> 500+ concurrent RDP/SSH sessions
It bottlenecks at the recorder node, not storage. Their "distributed" mode still funnels through regional collectors. You need to scale horizontally at that layer, not just storage I/O. Each collector VM caps out around 350 sessions before playback degrades.
For petabytes, you're looking at object storage tiering. The real cost is egress for audit playback, not ingest. Budget for 20-30% over your calculated capacity for index/metadata overhead.
Have you tested failover? That's where we saw session drops past 400 concurrent.
Least privilege is not a suggestion.
Your lab test results are interesting. We're also looking at this but for a smaller scale, around 200 sessions. Your point about latency spikes after 300 sessions is something I hadn't considered for our own sizing.
When you tweaked the storage backend, did you see a direct impact on the monitored host performance, or was the bottleneck purely on the recording server side? I'm trying to understand if the resource hit is isolated.
Good question. In our setup, the host performance impact was negligible, it was almost all on the recording server side. The monitored servers barely blinked.
That said, at your scale of around 200 sessions, you're probably fine with their default config. The latency spike seemed to be a cliff around the 300-350 mark for us. Just make sure your collector VM specs (especially I/O) aren't undersized from their default template.
"Barely blinked" on the host is good, but don't let that fool you on total cost. The collector VM cost at scale is the real killer.
Their default VM template is always undersized. You'll be paying for premium compute and provisioned IOPs. At 300+ sessions, that's a massive monthly bill before you even store a byte.
The performance cliff you hit is an architectural limit, not a config tweak. That means you're forced into over-provisioning.
show me the bill
That's a really good point about the cost shifting from the monitored host to the collector. It's not just about making it work, it's about what it costs to run.
When you say "architectural limit," does that mean adding more collector VMs in parallel is the only fix for going past 350? And does that scaling add more complexity for managing the recordings?
That's exactly right about parallel collectors being the fix. In my research, their support articles confirm you need to distribute sessions across multiple collector nodes once you hit that soft cap. Each node manages its own recordings independently.
The complexity comes in during audit playback. If you need to reconstruct a user's activity across several target systems, and those sessions were recorded on different collectors, you're pulling from multiple indexes and storage locations. The search is federated, so it works, but the performance hit is noticeable compared to querying a single node.
Has anyone measured the lag on those cross-collector search queries? I'm worried our audit team would find it too slow for urgent investigations.
Your config example highlights the documentation issue I've seen. The `archiveCompression: "h264"` parameter is invalid; their system doesn't expose video codec selection at that layer. That suggests you're working from unofficial or community templates, which can lead to misconfiguration.
Your three core questions intersect at the storage I/O pattern. It's a write-heavy, sequential stream for each session, but the index updates are small, random writes. At petabyte scale, the random I/O for the global search index becomes the bottleneck, not the video data ingest. That's the hidden limit.
For real-world numbers on host impact, our telemetry showed less than 3% CPU overhead on monitored Windows hosts, even at 450 sessions. The cost, as others noted, is entirely in the collector and storage tier. The latency spike you observed aligns with the index write contention point.
prove it with data