Secret Server Performance and Sizing Guide

Introduction

This Delinea Secret Server Performance and Sizing Guide (2025 Edition) provides updated recommendations for architecting and scaling your Secret Server deployment. Using recent performance benchmarks, this document offers insights and guidance, helping you design an environment that meets your organization's needs.

Performance Testing Overview

Most recommendations in this guide are supported by dedicated performance testing conducted in controlled environments.

Test Environment Setup

Performance benchmarks were established using clean, isolated infrastructure provisioned in Amazon Web Services (AWS), with no competing workloads. Each test environment was provisioned via Terraform, ensuring consistency, eliminating resource contention, and allowing for rapid deployment and adjustment of computing resources, instance types, and endpoint volumes. AWS user data scripts automated endpoint configuration, enabling comprehensive testing from a single command.

Benchmark Reference

The table below consolidates the per-DE (or per-node) throughput numbers used throughout this guide so you can see them in one place without chasing them across multiple sections. Detail sections later in the guide explain caveats and combined-DE behavior.

Workload Per-DE / Per-Node Throughput Tested Instance
Windows Local Account Discovery ~3,700 endpoints/hour (1 DE); ~7,500 endpoints/hour (2 DEs) c5a.2xlarge
Windows Local Accounts + Dependency Discovery ~3,400 endpoints/hour (1 DE); ~6,900 endpoints/hour (2 DEs) c5a.4xlarge / c5a.2xlarge
Active Directory (LDAP) Computer Object Discovery Thousands of objects in minutes (negligible load) c5a.2xlarge
Unix Network Discovery (single /22 subnet) ~36,700 endpoints/hour c5a.2xlarge
Unix Computer Scan (account enumeration) ~30,000–40,000 endpoints/hour (1 DE) c5a.2xlarge / c5a.4xlarge
Heartbeats — Windows Local Accounts ~36,000 secrets/hour (10 secrets/sec) t2.xlarge
Heartbeats — Unix ~28,800 secrets/hour (8 secrets/sec) t2.xlarge
Remote Password Changes — Unix ~6,480 secrets/hour (1.8 secrets/sec) t2.xlarge
Remote Password Changes — Mixed (Windows/Unix) ~7,200–14,400 secrets/hour t2.xlarge
SSH Proxying ~300 concurrent sessions/node Quad-core, 16 GB RAM
RDP Proxying ~100 concurrent sessions/node Quad-core, 16 GB RAM
Session Recording (standard worker) ~400–450 video hours/day Standard web node
Session Recording (Intel Quick Sync worker) ~1,500–2,000 video hours/day Quick Sync-enabled node
API requests (lightweight calls) ~500–1,000 requests/sec m5.large
Web UI requests (light use) ~1,000–2,000 requests/sec m5.large

Test Design Benefits

  • Scalability: Flexible scaling of endpoints and computing resources for varied test scenarios.
  • Cost efficiency: Lower costs compared to physical data-center setups, enabling frequent and extensive testing to replicate enterprise-scale scenarios.
  • Versatility: Adaptable environment saves setup time for future performance evaluations.
  • Consistency and accuracy: Reliable, repeatable results improve the accuracy and trustworthiness of performance benchmarks.

Core Sizing Principles

Component Roles

  • Application servers (web nodes): Handle UI/API requests, orchestrate workflows, and publish tasks to RabbitMQ.
  • Distributed engines (DEs): Consume tasks from RabbitMQ and execute operations like discovery, heartbeats, Remote Password Changes (RPC), and proxying.
  • Database servers: Store all Secret Server data; performance is critical.
  • RabbitMQ: Message queue facilitating asynchronous task processing between web nodes and DEs.

General Recommendations

  • Redundancy: Implement N+1 redundancy for all critical components (web nodes, DEs per site, Database, RabbitMQ) to ensure high availability and minimize downtime.

  • DE Task Allocation:

    • Deploy at least two DEs per site for high availability.
    • Limit discovery tasks to 50–60% of DE capacity. For the occupancy formula and multi-site engine sizing, see Engine Sizing per Site — this is the section you'll want when translating these rules into an actual DE count.
    • Example: Scanning 50,000 machines for local accounts (~7,500 endpoints/hour with dual c5a.2xlarge DEs, ~6.6 hours) every 24 hours yields ~28% discovery occupancy (6.6/24). Scanning every 8 hours increases occupancy to ~83% (6.6/8), requiring 1–2 additional DEs per site.
    • For workload-specific DE sizing (for example, heartbeats, RPC), see Heartbeats (HB) and Remote Password Changes (RPC).

  • Instance selection: For dedicated hardware and software specifications, refer to the Delinea Secret Server System Requirements. Prioritize compute-optimized instances (such as, AWS c5a series) for DEs handling CPU-intensive tasks like discovery and RPC. web nodes can use our minimum recommended system requirements unless handling proxying or session recording, which benefit from higher CPU (for example, c5a.2xlarge). For environments deploying both Secret Server and Privilege Manager on the same web nodes, use higher-spec instances. Combine disk space requirements for both applications.

  • Database performance: The database is often a key performance influencer. Ensure adequate CPU, RAM, and high IOPS. Address database performance before extensively scaling web or DE tiers. Ensure dedicated database resources to avoid contention.

  • Session recording: For basic session recording requirements, refer to the Basic Session Recording Requirements. For advanced session recording requirements, refer to the Advanced Session Recording Requirements.

Environmental and Compliance Considerations

Environments with stringent auditing, extensive SIEM integration, or data-at-rest encryption may introduce performance overhead. Apply a compliance overhead buffer (for example, +10–15% to resource calculations) in such scenarios.

Cross-Component Scaling Interactions

Rule of thumb: As you scale any tier, verify that the adjacent tiers have headroom before adding more capacity. Scaling DEs without database write headroom moves the bottleneck from DE throughput to audit-log contention. Scaling web nodes without API token caching moves the bottleneck from node capacity to database read pressure. Before scaling further, check RabbitMQ queue depth, database I/O, and DB query latency per Monitoring and Iterative Sizing. If those metrics lag, additional nodes won't translate to throughput — you'll just shift where the wait happens.

Workload-Specific Sizing Guidance

Discovery Operations

We recommend dedicated DEs, potentially within a distinct "discovery site," for environments with significant or time-sensitive discovery requirements. The endpoint count is the primary driver of scan duration, as each requires individual connection and processing. Performance metrics assume low-latency (<20ms) connections to endpoints; higher latency (>50ms) may reduce throughput, requiring additional DEs or regional sites. web servers with the engine worker server role enabled can process discovery responses, enhancing efficiency. However, these nodes also handle other tasks (for example, UI, API), so they cannot be dedicated solely to discovery. For high discovery loads, prioritize dedicated DEs (see Engine Sizing per Site).

For quick discovery sizing, estimate DE needs as follows:

  • Local Accounts: 1 DE ~3,600 endpoints/hour; each additional DE ~1,800/hour.
  • Local Accounts + Dependencies: 1 DE ~1,800/hour; each additional DE ~900/hour.
  • Example: 25,000 endpoints in 8 hours (local accounts) requires ~3,125/hour. 1 DE (3,600/hour) is sufficient. For 4.5 hours, use 2 DEs (~5,400/hour).

For detailed metrics or precise sizing with specific instance types (for example, c5a.2xlarge), see:

Discovery Sizing Considerations

Accurate discovery sizing requires understanding your requirements and environmental constraints. Ask the following questions to validate inputs:

  • Scan Frequency: How often must discovery run (such as, hourly, daily, or weekly)?
  • Completion Time: How quickly must scans complete (for example, <8 hours)?
  • Endpoint Count: Is the total number of systems accurate? Will discovery scale gradually (for instance, phased rollout)?
  • Contention: Are other features (for example, heartbeats, RPC, proxying) heavily utilized, potentially impacting DE capacity?

Guidance: Verify endpoint counts, as initial estimates may include future growth. For phased rollouts, start with fewer DEs and scale as endpoints increase. Ensure discovery occupancy remains <50–60% to avoid contention with other tasks (see Engine Sizing per Site).

Active Directory (AD) Computer Object Discovery

This discovery efficiently queries AD via LDAP for computer objects. Minimal load, no remote endpoint execution.

Guidance: A single DE (for example, c5a.2xlarge) can handle thousands of AD computer objects in minutes. This is not a sizing constraint.

Windows Local Account Discovery

This discovery connects to Windows endpoints (RPC/WMI) to enumerate local accounts. Endpoint count drives scan duration due to connection/query overhead. Benefits from parallel processing with multiple DEs.

Performance (Endpoints/Hour):

  • Dual c5a.2xlarge (16 total vCPUs, 2 DEs): ~7,500 endpoints/hour (for 507 endpoints, 1,506 accounts).
  • Single c5a.2xlarge/c5a.4xlarge (8 or 16 vCPUs, 1 DE): ~3,700 endpoints/hour.
c5a.4xlarge had no meaningful throughput improvement over c5a.2xlarge for this workload — endpoint I/O is the bottleneck, not DE CPU.

Guidance: Use 2+ DEs for >500 endpoints to reduce scan time. DEs with 8 vCPUs (such as, c5a.2xlarge) are optimal; scaling out is more effective than scaling up beyond 8 vCPUs.

Windows Local Accounts Plus Dependency Discovery

This extends local account discovery to identify application/service dependencies, adding processing per endpoint. Endpoint count remains the primary driver.

Performance (Endpoints/Hour):

  • Dual c5a.2xlarge (16 total vCPUs, 2 DEs): ~6,900 endpoints/hour (for 507 endpoints, 1,506 accounts).
  • Single c5a.4xlarge (16 vCPUs, 1 DE): ~3,400 endpoints/hour.

Guidance: Use multi-DE configurations for large endpoint counts. Expect ~10–15% throughput reduction compared to local accounts-only discovery due to dependency processing.

Unix Network Discovery (Endpoint Identification)

This discovery sweeps subnets (for example, /22, /24) via SSH to identify responsive hosts and gather metadata without login. IP range size and host density drive duration.

Performance (Endpoints/Hour):

  • c5a.2xlarge (1 /22 subnet, 1 DE, 8 vCPUs): ~36,700 endpoints/hour.
  • c5a.2xlarge (2 /24 subnets, 2 sources, 2 sites, 2 DEs, 8 vCPUs): ~45,000 endpoints/hour.
  • c5a.2xlarge (2 /24 subnets, 1 source, 1 site, 2 DEs, 8 vCPUs): ~26,000 endpoints/hour.
  • Larger ranges (for example, 10 x /22, single site): ~4,100 endpoints/hour.

Guidance: Use a single c5a.2xlarge for a large segment. For multiple segments, create separate sources/sites with dedicated DEs to scan in parallel, as additional DEs on a single segment yield diminishing returns.

Unix Computer Scan (Account Enumeration)

This scan establishes SSH sessions to Unix endpoints to retrieve local accounts. Endpoint count drives duration due to SSH connection overhead.

Performance (Endpoints/Hour):

  • t2.xlarge (3 DEs, 4 vCPUs each): Up to 90,000 (for 100 endpoints).
  • c5a.4xlarge/c5a.2xlarge (1 DE, 8 or 16 vCPUs): ~30,000–40,000 (for 500 endpoints).2
c5a.4xlarge had no meaningful throughput improvement over c5a.2xlarge for this workload — endpoint I/O is the bottleneck, not DE CPU.

Guidance: Throughput scales with DE count. For small to moderate counts (<1,000), t2.xlarge is cost-effective. For larger volumes (>1,000), prefer c5a.2xlarge or c5a.4xlarge for sustained throughput.

Discovery Sizing Reference Table

The table below provides approximate discovery times for Windows Local Account discovery across enterprise scales, assuming dual c5a.2xlarge DEs (~7,500 endpoints/hour) and additional DEs for faster completion.

Enterprise Size Endpoints Per-DE Rate (endpoints/hour) Time with 1 DE Desired Time DEs Needed (Total) Time with DEs Needed
Small 2,000 ~3,750 ~0.5 hours <1 hour 1 ~0.5 hours
Medium 25,000 ~3,750 ~6.7 hours <4 hours 2 ~3.3 hours
Large 50,000 ~3,750 ~13.3 hours <8 hours 2 ~6.7 hours
Massive 100,000 ~3,750 ~26.7 hours <12 hours 3 ~8.9 hours

Guidance: Use this table for initial sizing estimates. Adjust based on specific requirements (for instance, scan frequency, dependency discovery) and environmental factors (for example, latency).

For detailed metrics, see:

See Engine Sizing per Site for site-level sizing.

Heartbeats (HB)

Heartbeat verifies stored credentials against target systems. Performance is primarily influenced by target system responsiveness and network latency, with DE CPU as a secondary factor.

Performance Metrics (per t2.xlarge, 4 vCPUs):

  • Windows Local Accounts: ~9–10 secrets/sec (~32,400–36,000 secrets/hour).
  • Unix: ~8 secrets/sec (~28,800 secrets/hour).
  • Dual DEs: ~14–20 secrets/sec (~50,400–72,000 secrets/hour, mixed targets).
  • Capacity Insight: DEs are capable of >100 secrets/sec with RabbitMQ backlog and fast target responses, indicating DEs often wait in steady-state operation.

Sizing Guidance:

  • Calculate Hourly Heartbeat Load: Divide total secrets by heartbeat interval (for example, 8 hours). For 25,000 secrets, ~3,125 heartbeats/hour.
  • DE Requirements: DEs required = (heartbeats per hour / ~36,000 secrets/hour per t2.xlarge). Round up and add 1 for redundancy. A single t2.xlarge handles ~3,125 heartbeats/hour with spare capacity.
  • Redundancy: Deploy 2+ DEs per site for N+1 redundancy.
  • Performance Optimization: If queues grow or completion times lag, investigate target system performance (such as, latency, timeouts) before adding DEs.
  • Workload Balance: Heartbeats are rarely the primary driver for DE count, as discovery is more resource-intensive (see Engine Sizing per Site).

Example scenario: Validate 75,000 credentials in <2 hours across three regions. Assume credentials distribute as: Site 1 = 40,000 (high-density), Site 2 = 25,000 (medium), Site 3 = 10,000 (low).

  • Site 1: 40,000 / 2 hours = 20,000/hour. 20,000 / 36,000 ≈ 0.56 → 1 DE + 1 for N+1 = 2 DEs. Add a third if latency budget is tight.
  • Site 2: 25,000 / 2 hours = 12,500/hour. 12,500 / 36,000 ≈ 0.35 → 1 DE + 1 for N+1 = 2 DEs.
  • Site 3: 10,000 / 2 hours = 5,000/hour. Easily fits 1 DE + 1 for N+1 = 2 DEs.

Total: 6 DEs across three sites, with 2 per site for N+1 redundancy. Monitor RabbitMQ queue depths and target latency.

Remote Password Changes (RPC)

RPC automates password rotation on target systems. More CPU-intensive than heartbeats due to authentication, password generation, and updates. Performance varies based on target system policies (for example, password complexity, change propagation).

Performance Metrics (per t2.xlarge, 4 vCPUs):

  • Unix: ~1.8 secrets/sec (~6,480 secrets/hour).
  • Dual DEs: ~3.3 secrets/sec (~11,880 secrets/hour).
  • Three DEs: ~5.0 secrets/sec (~18,000 secrets/hour).
  • Mixed workload (Windows/Unix): ~2–4 secrets/sec (~7,200–14,400 secrets/hour).

Sizing Guidance:

  • Calculate Hourly RPC Load: For monthly schedules, divide secrets by 720 (24 hours × 30 days). For 25,000 secrets, ~35 password changes per hour.
  • DE Requirements: DEs required = (password changes per hour / ~7,200 secrets/hour per t2.xlarge). A single t2.xlarge handles ~35/hour easily.
  • Redundancy: Deploy 2+ DEs per site for N+1 redundancy.
  • Emergency Rotations: For rapid rotations (for example, post-breach), assume ~2 secrets/sec per DE and add +1–2 DEs buffer for latency or target issues.
  • Steady-state vs. peak sizing: RPC DE count is driven by peak rotation requirements (post-breach, audit-driven mass rotation), not scheduled rotations. Scheduled monthly/quarterly rotations of comparable volume run at <100/hour and are absorbed by any N+1 deployment. Size for peak; steady-state is covered.
  • Workload Balance: RPC is rarely the primary driver for DE count (see Engine Sizing per Site). Monitor RabbitMQ queues and target response times during rotations.

Example scenario: You require the ability to rotate 50,000 secrets (Windows/Unix) in <1 hour post-breach.

  • Calculation: 50,000 secrets / 1 hour = 50,000 secrets/hour. Per t2.xlarge: ~7,200 secrets/hour. DEs required: 50,000 / 7,200 ≈ 6.94, round up to 7. Add 1–2 DEs buffer = 8–9 DEs.
  • Recommendation: Deploy 9 DEs across sites, with 2+ DEs per site. Monitor DE CPU and RabbitMQ queue depths.

SSH and RDP Proxying

Secret Server securely tunnels SSH and RDP sessions, enabling controlled access. Proxy sessions can be handled by web servers or DEs, with no inherent capacity difference. Sessions are assigned round-robin. Performance varies by activity and environmental factors.

Performance (per node, web server or DE, Intel 3.7 GHz Quad Core, 16 GB RAM equivalent):

  • SSH: ~300 concurrent sessions (standard activity, for instance, file navigation, editing on Linux).
  • RDP: ~100 concurrent sessions (standard activity, for example, opening MMC snap-ins, editing files on Windows).
  • Heavy Data Transfer: ~150 combined sessions (SSH + RDP) for large file transfers or high-bandwidth activities (for example, video streaming).
  • Light Activity: May exceed 400 combined sessions for minimal operations (such as, basic commands).
Proxying via DEs is less efficient if session recording is enabled (see Session Recording), due to traffic capture and RabbitMQ queuing overhead.

Guidance:

  • Node selection: Prefer web servers if DEs are busy with session recording, discovery, or other tasks. Ensure DEs have sufficient CPU/memory for combined workloads.
  • Dedicated nodes for high loads: For 1,000 concurrent SSH sessions, capacity is ~4–5 nodes (1,000 / 200–250 sessions/node). Add 1 for N+1 redundancy = 5–6 nodes.

Key Performance Factors:

  • Latency: Minimize end-user-to-node latency. Lower latency to web servers vs. DEs may improve efficiency.
  • CPU resources: Proxying is CPU-intensive, especially for RDP. Scale to higher-core instances (for example, c5a.2xlarge) if needed.
  • Network bandwidth: Ensure 100 MB/s for standard activity, 1 GB/s for heavy transfers.
  • Fine tuning: If performance degrades: reduce latency, increase CPU (for instance, c5a.4xlarge), test web server proxying if DEs show contention, and monitor CPU, network, and session latency.
  • Redundancy: Deploy 2+ proxy-enabled nodes per site for N+1 redundancy.
  • SSH public address: Multiple web servers' SSH public addresses impact routing/firewall configurations.

Example scenario:

  • 1,000 concurrent SSH sessions with standard activity, minimal recording.

    • Calculation: Capacity ~200–250 sessions/node → 1,000 / 200–250 ≈ 4–5 nodes. Add 1 for N+1 redundancy = 5–6 nodes.
    • Recommendation: Deploy 5–6 dedicated web servers (for example, c5a.2xlarge, 100 MB/s bandwidth). Ensure low latency. Offload recording to separate nodes (Session Recording). Monitor CPU/network metrics.

Heavy API Use

Tuning for programmatic interaction with Secret Server via APIs.

Performance: A single web node (for example, m5.large, 2 vCPUs, 8 GB RAM) handles ~500–1,000 API requests/sec for lightweight calls (such as, secret retrieval). Resource-intensive calls (for example, bulk updates) reduce throughput by 50–70%.

Guidance:

  • Allocate 2+ dedicated web nodes for API traffic, with a separate load balancer endpoint (for instance, AWS ELB, F5).
  • Encourage API clients to cache authentication tokens.

Be mindful of resource-intensive calls (for example, bulk updates, broad searches). High-impact API calls include:

  • Authentication requests (cache tokens to reduce frequency).
  • File uploads (such as, secret attachments).
  • Downloading session recording videos (offload to dedicated storage).
  • Update operations (for example, bulk updates, folder moves, more taxing than Get calls).

Guidance:

  • Optimize these calls through caching, batching, or isolating to dedicated nodes.
  • Monitor application server CPU/RAM and database performance under API load.

Session Recording

Session recording records proxied sessions for audit/review.

Guidance:

  • Client session launching: ~100 sessions per web node.
  • Video encoding (transcoding): Default 2 concurrent transcodes per Session Recorder worker role-enabled web node. Scale horizontally.

Processing Capacity:

  • Standard Node: ~400–450 hours of video/day.
  • Intel Quick Sync Node: ~1,500–2,000 hours/day.
It is likely cheaper to buy additional web node licenses than it would be to buy hardware dedicated for this function.

Storage: ~15 hours/GB (~27 GB/day for 400 hours). Use high-performance, SSD-backed file shares (for example, AWS EFS, NetApp). To manage storage costs, archive session recordings to slower/cheaper storage (such as, AWS S3, cold storage). For encrypted recordings, restore to the original high-performance file share for playback in Secret Server. Plan archival strategies to balance cost and compliance requirements.

Sizing Equations:

  • Web nodes for launching = (max concurrent sessions / 100).
  • Session recording worker nodes (standard): total daily video hours ÷ 400.
  • Session recording worker nodes (Intel Quick Sync): total daily video hours ÷ 1,500.
  • Dedicate web nodes with session recorder role: CPU is primary for transcoding. Deploy 2+ nodes per site for N+1 redundancy.
For additional recommendations and session recording capacities, refer to the Session Recording Caveats and Recommendations and System Capacity Specifications.

Web UI Traffic

These are interactive user sessions.

Performance: A single web node (for example, m5.large) handles ~1,000–2,000 UI requests/sec for light use (for instance, credential vault). Heavy feature use (for example, reports, searches, dashboards) reduces throughput by 30–50%.

Guidance:

  • A single web node supports 5,000+ concurrent UI sessions for light use.
  • For active environments with heavy feature use, start with 2 web nodes for HA and load distribution.
  • Isolate UI traffic to dedicated web nodes if impacted by API or background processing.
  • Monitor CPU/RAM use.

Engine Sizing per Site

DEs handle discovery, heartbeats, RPC, and other tasks. Sites are logical groupings of DEs, often aligned with geographical/network boundaries. Proper sizing ensures balanced workloads and high availability.

Sizing Guidance:

  • Workload Balance: Limit discovery to 50–60% of DE capacity for heartbeats, RPC, and more. (see Discovery Operations, Heartbeats (HB), and Remote Password Changes (RPC)).
  • Redundancy: Deploy 2+ DEs per site for N+1 redundancy.
  • Discovery-Driven Sizing: Calculate DEs based on discovery needs (Discovery Operations). Estimate occupancy: (discovery scan duration / scan interval). If >50–60%, add DEs.
  • Multi-Site Considerations: Create sites with dedicated DEs to minimize latency for regional endpoints.

Example scenario:

  • Scan 25,000 machines for Windows local accounts every 24 hours, <50% occupancy.

    • Calculation: Dual c5a.2xlarge (~7,500 endpoints/hour): 25,000 / 7,500 ≈ 3.33 hours. Occupancy: 3.33 / 24 ≈ 14%. Every 8 hours: 3.33 / 8 ≈ 42%.
    • Recommendation: 2 DEs per site (redundancy, low occupancy). For 8-hour scans, consider 3 DEs. Monitor CPU and RabbitMQ.

Large-scale example:

  • 75,000 endpoints every 8 hours, 3 sites.

    • Calculation: Dual c5a.2xlarge: 75,000 / 7,500 ≈ 10 hours. For <8 hours, use 3–4 DEs/site (75,000 / ~11,250 ≈ 6.67 hours). Occupancy: 6.67 / 8 ≈ 83%. Add 1–2 DEs/site = 4/site, 12 total.
    • Recommendation: Deploy 4 DEs/site (12 total), ensuring <50% occupancy. Adjust for heartbeats/RPC (Heartbeats (HB) and Remote Password Changes (RPC)).

Combined Use Cases and Example Scenarios

Prioritize sizing for the most resource-intensive or time-critical workload (for instance, Session Recording, discovery/RPC with tight deadlines), then layer other requirements.

Example 1 (discovery, proxy, recording):

  • 50,000 systems (Windows Local Accounts, 8-hour target) discovery, 500 concurrent SSH sessions, 200 concurrent recordings.

    • Session Recording Launching: 200 / 100 = 2 web nodes with Session Recording Worker role enabled.
    • Session Recording Processing: 8 hours/day × 200 sessions = 1,600 hours/day. 1,600 / 400 = 4 standard worker nodes (or ~1 quick-sync node).
    • SSH Proxy: 500 / 200–250 ≈ 2–3 dedicated web nodes.
    • Discovery: 50,000 endpoints: ~7 DEs (50,000 / ~7,500, dual c5a.2xlarge).
    • Additional: 1–2 web nodes for UI/API if not covered.

Example 2 (large discovery, recording, hb/rpc, growth): 75,000 accounts discovery, 100 concurrent recordings, HB/RPC for all, user growth from 500 to 2,000.

Initial:

  • UI web nodes: 2 (m5.large). For 2,000 users, assume 1–2 UI sessions/user (~2,000–4,000 sessions). Assess if 2 nodes suffice or add 1–2.
  • Session Recording Launching: 100 / 100 = 1 web node.
  • Session Recording Processing: 800 hours/day (8 hours × 100): 800 / 400 = 2 worker nodes.
  • Discovery/HB/RPC DEs: 75,000 accounts in 10 hours (~4 DEs, c5a.2xlarge). Add capacity for HB/RPC (14 hours free; start with 4–6 DEs, monitor).

3-Year Growth (15,000 accounts, 150 recordings):

  • Session Recording: ~2 more worker nodes.
  • Discovery/HB/RPC: ~1–2 more DEs.

Addressing Large-Scale Sizing Questions

While Secret Server is built to be enterprise ready, we have not had many customers whose environments exceed the conditions above. Sales engineers, partners, and consultants should work directly with Delinea Solutions Architects to properly size Secret Server environments that fit any one of the following parameters:

  • 100,000+ secrets
  • 500+ concurrent session recordings
  • 5,000+ simultaneous active UI web sessions
  • 50,000+ systems for frequent, full discovery
  • 1,000+ simultaneous SSH/RDP proxy sessions
Please do not reach out to developers directly to help with sizing requests. Solution Architects will work with R&D directly if necessary to help size environments exceeding any of these numbers.

Monitoring and Iterative Sizing

Sizing is iterative. Continuously monitor:

  • RabbitMQ: Queue depths, message rates.
  • DEs: CPU utilization, task processing times, error logs.
  • Application servers: CPU/RAM, request latencies, API metrics.
  • Database servers: CPU/RAM, Disk I/O (IOPS, latency, queue depth), query performance.
  • Secret Server application logs: Performance insights, errors. Adjust resources based on observed performance, changing requirements, and user feedback to maintain optimal performance.