Issuing a certificate through Skyrsoft CertOps does real computational work — generating an RSA-2048 keypair and signing the result — so throughput is limited by available CPU rather than by the network or the database. The numbers below are lab measurements taken directly against a reference server, not an estimate, and the method used to take them is repeatable against your own hardware.
How it works
The reference server (an Intel Core Ultra 7 265T: 8 performance cores base 1.5 GHz, 12 efficiency cores base 1.2 GHz, turbo to 5.3 GHz) was driven with enrolment requests at increasing concurrency while server CPU was sampled every second throughout, at two vCPU allocations.
| vCPUs | Concurrent clients | Requests | Wall time | p50 latency | p95 latency | Throughput | Peak CPU |
|---|---|---|---|---|---|---|---|
| 3 | 10 | 20 | 8.9s | 4.00s | 4.45s | 2.2/sec* | 100% |
| 3 | 25 | 50 | 8.8s | 3.52s | 4.47s | 5.7/sec | 100% |
| 3 | 50 | 100 | 17.0s | 5.06s | 7.68s | 5.9/sec | 100% |
| 4 | 10 | 20 | 3.3s | 1.11s | 1.48s | 6.0/sec | ~100% |
| 4 | 25 | 50 | 6.9s | 2.72s | 3.72s | 7.3/sec | 100% |
| 4 | 50 | 100 | 13.2s | 5.67s | 7.29s | 7.6/sec | 100% |
Zero requests failed across either test, 441 issuances in total.
The first burst after idle is not the steady-state number
* The 3-vCPU server’s first burst ran at under half the throughput of the two that followed it, despite CPU already reading 100%. That is a CPU frequency effect, not a capacity ceiling: this processor’s cores idle at their 1.5 GHz base clock and only reach their 5.3 GHz turbo ceiling after a few seconds of sustained load, and the first burst was measured from idle. The second and third bursts, run back-to-back with no idle gap, land on the same plateau as the 4-vCPU test’s steady state once the difference in core count is accounted for. The 4-vCPU test showed no such effect — CPU jumped straight to 95–100% and produced consistent throughput from the first request.
Using each test’s steady-state plateau (excluding the 3-vCPU test’s cold first burst): 3 vCPUs sustain roughly 1.9 certificates per second per core, 4 vCPUs roughly 1.86 — within about 4% of each other, which is a reasonable sign that throughput on this workload scales close to linearly with core count on this hardware. It is still one server measured at two core counts, not a scaling study across different hardware.
The renewal thundering herd
Initial enrolment is rarely the real capacity risk in practice — real device provisioning is naturally staggered by how long each machine takes to boot, network and install an agent. The risk that’s easy to miss shows up roughly a year later: certificates renew on a fixed day-count threshold before expiry (30 days by default), checked on every device’s heartbeat with no random jitter added. Devices enrolled in the same window will re-enter that renewal window in the same relative window again, so a same-day mass enrolment produces a same-few-minutes mass renewal a year on — not one smoothed evenly across the 30-day threshold. Since heartbeats run every few minutes rather than daily, that concentrates a year’s worth of staggering back into a single burst. Spreading an initial rollout over one to two weeks rather than a single day costs nothing operationally and directly smooths the spike it would otherwise create at renewal; if a compressed rollout is unavoidable, size for the renewal peak (fleet size divided by the heartbeat interval in seconds) rather than for the initial enrolment rate, which can understate it by an order of magnitude for the same total amount of work.
Running a sizing test
Measure your own target hardware rather than extrapolating from the numbers above. Create a short-lived API key scoped to Enrol only, point it at an active, auto-approving template, and time a batch of enrolment requests at a few concurrency levels the same way the reference test was run — watching server CPU throughout is what tells you whether you’ve found a real ceiling or are still warming up. Run the first burst from an idle server and at least one more immediately after with no gap, since the cold-start effect above can make a single measurement look like a lower ceiling than the server actually has. Afterwards, revoke the test certificates and delete the API key.
Limits
These figures come from one physical host, measured at two vCPU allocations. Use them as a starting point for reasoning about your own hardware, then run the same test against it. CPU generation, clock speed and whatever else is competing for the same cores all move the ceiling.
A cold server understates its own steady-state throughput. A sizing test run as a single burst from idle can read as a lower ceiling than the server actually sustains once its cores are warmed up; run at least two consecutive bursts before drawing a conclusion from either one.
This measures issuance throughput specifically, not the server’s behaviour under a mixed production workload. Deployment pushes, approval-rule evaluation, audit forwarding and console use all compete for the same CPU during a real renewal spike, which the isolated test above does not model.