Skip to content
Notifications
Clear all

What is the actual concurrent session limit before slowdown?

1 Posts
1 Users
0 Reactions
0 Views
(@cost_analyst_liam)
Reputable Member
Joined: 3 months ago
Posts: 146
Topic starter   [#8618]

I've been conducting a detailed cost and performance analysis for a client considering a broad rollout of Delinea Secret Server across their development and operations teams. The architectural documentation and sales materials are clear on the *licensed* concurrent session limits, which are tiered (e.g., 25, 50, 100, etc.). However, my practical concern—and the reason for this thread—is to understand the *actual* performance degradation curve as one approaches and exceeds that licensed limit.

From a FinOps and capacity planning perspective, simply knowing the hard cap is insufficient. We need to model the performance impact to make an informed decision on license tiering. Over-licensing is a clear cost inefficiency, but under-licensing that leads to productivity slowdowns during critical incidents is a far greater operational risk.

My specific questions for the community, based on your deployment experiences:

* At what utilization percentage of your licensed concurrent sessions do you begin to observe measurable latency in operations? For instance, at 80% utilization, is secret retrieval or session establishment still within the same sub-second range, or does it begin to taper?
* What is the behavior at the limit? Are new sessions queued gracefully, rejected outright, or do they cause contention that slows existing sessions?
* Has anyone conducted load testing slightly *over* the limit (e.g., 110-120%)? The critical data point is whether the system degrades linearly or falls off a cliff, potentially causing a cascading failure for all users.
* Are there specific components or workflows most sensitive to this load? Anecdotal evidence suggests that the web interface may exhibit slowdowns before the core API or PowerShell module, but I lack concrete data.

In my analysis of other enterprise software, the "concurrent session" metric often ties directly to the available worker threads or connection pools in the application server. Once exhausted, requests queue, increasing latency. I suspect a similar architecture here, but without internal metrics, it's guesswork.

I am collating any verifiable performance data, even if anecdotal, to build a more accurate total cost of ownership model. This model must factor in not just the license sticker price, but the risk-weighted cost of potential productivity loss.

-- Liam


Always check the data transfer costs.


   
Quote