A/B Testing CPU Requirement Formula
Learn how to estimate CPU cores for A/B test traffic using request volume, peak demand, CPU time, utilization targets, and headroom.
This calculation estimates the application CPU capacity needed to serve traffic included in an A/B test. It converts daily activity into a peak test request rate, estimates raw CPU work, then adds capacity for a utilization target and operational headroom.
- 100% Free
- No Sign-Up Required
- Private & Secure
- Mobile Friendly
Recommended CPU Cores
Where:
Estimate peak requests handled by the test, multiply by CPU work per request to get raw core demand, adjust for the utilization limit, add a buffer, and round up to a whole core.
Variables Explained
| Variable | What It Means | Unit |
|---|---|---|
| dailyUsers - Daily active users | Expected users who generate relevant application or API requests in one day. | users |
| requestsPerUser - Requests per user per day | Average number of relevant requests generated by each active user per day. | requests |
| testTrafficPercent - Traffic included in test | Percentage of total traffic assigned to the experiment. | percent |
| peakTrafficMultiplier - Peak traffic multiplier | Peak request rate divided by average request rate. | number |
| cpuMsPerRequest - CPU time per request | CPU processing time consumed by one request, excluding external waiting time where possible. | CPU ms |
| targetCpuUtilization - Target CPU utilization | Maximum planned sustained CPU utilization during peak test traffic. | percent |
| headroomPercent - Additional capacity headroom | Extra capacity for uncertainty, bursts, deployment overlap, and other workload variation. | percent |
| variantCount - Number of variants | Total traffic-serving versions in the experiment, including the control. | number |
Step-by-Step Calculation
Convert daily activity to average request rate
There are 86,400 seconds in a day, so daily request volume is divided by 86,400 to find the average requests per second.
averageRequestsPerSecond = dailyUsers * requestsPerUser / 86400
Find the experiment's average request rate
Only the selected share of application traffic is included in the A/B test.
testAverageRequestsPerSecond = averageRequestsPerSecond * testTrafficPercent / 100
Apply peak demand
The peak multiplier raises the average experiment traffic to the expected busy-period rate.
peakTestRequestsPerSecond = testAverageRequestsPerSecond * peakTrafficMultiplier
Calculate raw CPU demand
A CPU core supplies approximately 1,000 CPU milliseconds per second when fully utilized, so this converts CPU work into fully utilized core demand.
cpuCoresAtPeak = peakTestRequestsPerSecond * cpuMsPerRequest / 1000
Adjust for the utilization target
Planning below 100% utilization requires more provisioned capacity than the raw CPU demand.
usableCoreCapacity = cpuCoresAtPeak / (targetCpuUtilization / 100)
Add headroom and round up
Headroom is added after the utilization adjustment, then capacity is rounded up because CPU cores are provisioned as whole units in this estimate.
recommendedCpuCores = ceil(usableCoreCapacity * (1 + headroomPercent / 100))
Estimate capacity per variant
When traffic is split evenly, this gives a practical whole-core estimate for each separately deployed variant.
cpuCoresPerVariant = max(1, ceil(recommendedCpuCores / variantCount))
Worked example: two-variant experiment
Average request rate
100000 × 20 ÷ 86400
23.15 requests/sec
Average test traffic
23.15 × 50 ÷ 100
11.57 requests/sec
Peak test traffic
11.57 × 3
34.72 requests/sec
Raw peak CPU demand
34.72 × 15 ÷ 1000
0.52 cores
Capacity at 70% utilization
0.52 ÷ 0.70
0.74 cores
Headroom and rounding
ceil(0.74 × 1.25)
1 core
Per-variant estimate
max(1, ceil(1 ÷ 2))
1 core per variant
Final Result
Plan approximately 1 total CPU core for the experiment traffic. Where the two variants run as separate allocations, allow at least 1 core for each variant.
Assumptions
- ✓Daily users and requests per user represent a typical day with a reasonably stable distribution of traffic.
- ✓The peak traffic multiplier accurately represents the busiest relevant period.
- ✓CPU milliseconds per request measure application CPU work rather than database, network, or other waiting time.
- ✓Experiment traffic is split evenly across variants for the per-variant estimate.
- ✓The selected utilization target and headroom are appropriate for the deployment environment.
Limitations
- !The estimate does not separately size databases, caches, queues, storage, network capacity, or background workers.
- !Retries, cache misses, slow dependencies, logging, telemetry, and feature-flag evaluation can increase real resource use.
- !Averages may not reflect short spikes, regional bursts, bot traffic, or coordinated campaigns.
- !Container CPU limits, CPU throttling, instance overhead, and autoscaling behavior can affect capacity available in production.
- !The whole-core rounding can make small workloads appear larger when variants are deployed independently.
Common Mistakes to Avoid
Using total request latency as CPU time per request even though latency includes time waiting on dependencies.
Entering a peak multiplier of 1 when traffic has meaningful daily or event-driven peaks.
Applying the test traffic percentage to each variant instead of to the total experiment traffic.
Assuming two variants automatically require twice the total CPU for the same traffic volume.
Ignoring per-variant minimum allocations when variants run in separate containers or services.
Treating the result as a replacement for production-like load testing and monitoring.
Related Formulas
Frequently Asked Questions
How are CPU cores calculated for an A/B test?
The calculation finds peak test requests per second, multiplies that rate by CPU milliseconds per request, then adjusts the result for the target utilization and selected headroom.
Why is CPU time divided by 1,000 in the formula?
CPU time is entered in milliseconds per request. Dividing peak requests per second multiplied by CPU milliseconds by 1,000 converts the workload into fully utilized CPU cores.
Does the number of variants change total CPU core demand?
Not by itself when the same total test traffic and CPU work are split evenly. It can affect practical per-variant allocations when variants are isolated in separate deployments.
What does target CPU utilization mean in this calculation?
It is the maximum sustained utilization used for planning at peak load. A lower target creates more provisioned capacity than planning at a higher target.
Why does the result round up to a whole CPU core?
The formula rounds up so the estimate does not understate the capacity needed after utilization and headroom are applied.
Should CPU time per request include database wait time?
No. Use CPU processing time where available. Database or network wait time should be assessed separately because it affects other capacity constraints.
Ready to calculate your result?
Use the calculator to get instant results with your own inputs.