Having recently completed a comprehensive load test of the Delinea (formerly Thycotic) Secret Server API, specifically focusing on its capacity for programmatic secret rotation, I feel compelled to share some concrete findings. The vendor's documentation provides high-level scalability claims, but when designing a system for automated, large-scale credential rotation—think thousands of database passwords or service accounts—empirical throughput data is critical for architecture decisions and total-cost-of-ownership projections.
Our test harness was designed to simulate a realistic FinOps-driven rotation schedule, where batches of secrets are rotated during maintenance windows. We utilized the `POST /api/v1/secrets/{id}/rotate-now` endpoint, with authentication via OAuth2 client credentials. The environment was a dedicated application node (8 vCPUs, 32GB RAM) within our Azure tenant, communicating with a Delinea instance hosted in the vendor's US-East data center. All secrets in the test pool were of a "Windows Domain Account" type, configured with a PowerShell rotation script. Network latency averaged 22ms.
The results, averaged over three sustained one-hour runs, were as follows:
* **Maximum Sustained Single-Threaded Rate:** 12.2 successful rotations per minute (spm). This was achieved with a 5-second delay between API calls to avoid client-side throttling. The bottleneck was consistently the synchronous nature of the `rotate-now` call, which waits for the full rotation script execution to complete before returning.
* **Multi-Threaded Concurrency (10 threads):** 94.8 spm. Scaling was sub-linear, as expected. The primary constraint shifted from client-side network latency to server-side resource allocation (likely script engine execution pools). Error rates (HTTP 429, 502) increased to approximately 2.1% at this level.
* **Optimal Batch Size for Queue-Based Processing:** For our architecture, we found that queuing batches of 50 secrets, processed by 5 worker threads, yielded a reliable 48-52 spm with zero errors. This became our operational baseline.
Key technical observations for anyone planning similar workloads:
1. The API response time is dominated by the rotation script runtime. A 30-second script creates a 30-second API call. Benchmark your own scripts independently.
2. The `X-RateLimit-Remaining` header is present but unreliable under high concurrency; implement exponential backoff on HTTP 429.
3. For true bulk operations, the `POST /api/v1/secrets/change-password` endpoint (which updates the secret's password without executing the full rotation logic) is an order of magnitude faster but bypasses audit trails and workflow hooks—a critical trade-off.
These numbers have directly informed our cost model. At ~50 spm, rotating a portfolio of 10,000 secrets requires just over 3 hours of dedicated processing time, which impacts scheduling and compute resource reservation for our orchestration layer. I am keen to hear if others have conducted similar benchmarks, particularly with different secret types (e.g., SSH keys, AWS IAM) or in different hosting models (on-prem vs. cloud). Discrepancies in throughput can significantly alter TCO calculations for large-scale automation initiatives.
— Data-driven decisions.
Trust but verify.
This is exactly the kind of info I wish more vendors would provide upfront. When you mention network latency, was that the main bottleneck you observed, or did you hit any limits on the API side like rate limiting or a queue backlog? I'm planning something similar but on a smaller budget using a self-hosted instance.