A/B Testing CPU Requirement Calculator Examples
Worked A/B test CPU sizing examples for small launches, high-traffic experiments, multi-variant tests, and conservative capacity planning.
These examples show how traffic share, peaks, CPU work per request, utilization limits, and headroom change an A/B test CPU estimate. They are planning illustrations rather than production capacity guarantees.
Small feature experiment with two variants
A product team exposes a new interface to 25% of traffic while control and treatment are deployed separately.
Input Summary
Daily active users
20,000 users
Requests per user per day
12 requests
Traffic included in test
25%
Peak traffic multiplier
2×
CPU time per request
10 CPU ms
Variants
2
Target CPU utilization
70%
Headroom
25%
Calculation Breakdown
- 1Average application rate20000 × 12 ÷ 864002.78 requests/sec
- 2Peak test rate2.78 × 0.25 × 21.39 requests/sec
- 3Raw CPU demand1.39 × 10 ÷ 10000.014 cores
- 4Recommended capacityceil((0.014 ÷ 0.70) × 1.25)1 total core
Result Summary
Recommended capacity
1 total core
A/B Testing CPU Requirement Calculator
The formula recommends 1 total CPU core. Separately deployed control and treatment versions may each need a practical minimum allocation.
Half-traffic experiment on a busy application
An application places 50% of its traffic into an experiment during a period when the relevant request rate reaches four times the daily average.
Input Summary
Daily active users
500,000 users
Requests per user per day
30 requests
Traffic included in test
50%
Peak traffic multiplier
4×
CPU time per request
18 CPU ms
Variants
2
Target CPU utilization
70%
Headroom
25%
Calculation Breakdown
- 1Average application rate500000 × 30 ÷ 86400173.61 requests/sec
- 2Peak test rate173.61 × 0.50 × 4347.22 requests/sec
- 3Raw CPU demand347.22 × 18 ÷ 10006.25 cores
- 4Recommended capacityceil((6.25 ÷ 0.70) × 1.25)12 total cores
- 5Even-split variant estimateceil(12 ÷ 2)6 cores per variant
Result Summary
Even-split variant estimate
6 cores per variant
A/B Testing CPU Requirement Calculator
The experiment requires an estimated 12 total CPU cores, or about 6 cores per evenly split variant.
Four-variant experiment with uneven operational risk
A team tests four recommendation approaches across 80% of traffic and wants extra capacity for traffic variability and deployment overlap.
Input Summary
Daily active users
1,000,000 users
Requests per user per day
25 requests
Traffic included in test
80%
Peak traffic multiplier
3×
CPU time per request
12 CPU ms
Variants
4
Target CPU utilization
60%
Headroom
50%
Calculation Breakdown
- 1Average application rate1000000 × 25 ÷ 86400289.35 requests/sec
- 2Peak test rate289.35 × 0.80 × 3694.44 requests/sec
- 3Raw CPU demand694.44 × 12 ÷ 10008.33 cores
- 4Capacity before headroom8.33 ÷ 0.6013.89 cores
- 5Recommended capacityceil(13.89 × 1.50)21 total cores
- 6Even-split variant estimateceil(21 ÷ 4)6 cores per variant
Result Summary
Even-split variant estimate
6 cores per variant
A/B Testing CPU Requirement Calculator
The result is 21 total CPU cores, with an approximate 6-core allocation for each separately deployed variant.
Low test share with CPU-heavy requests
A service tests a CPU-intensive personalization routine on 10% of traffic, using a high peak multiplier from observed campaign periods.
Input Summary
Daily active users
150,000 users
Requests per user per day
16 requests
Traffic included in test
10%
Peak traffic multiplier
5×
CPU time per request
80 CPU ms
Variants
2
Target CPU utilization
75%
Headroom
20%
Calculation Breakdown
- 1Average application rate150000 × 16 ÷ 8640027.78 requests/sec
- 2Peak test rate27.78 × 0.10 × 513.89 requests/sec
- 3Raw CPU demand13.89 × 80 ÷ 10001.11 cores
- 4Recommended capacityceil((1.11 ÷ 0.75) × 1.20)2 total cores
Result Summary
Recommended capacity
2 total cores
A/B Testing CPU Requirement Calculator
The calculator estimates 2 total CPU cores for the experiment traffic.
How to Read Your Results
Peak test request rate is the estimated busy-period rate handled by the experiment, not the average rate across the full day.
Raw peak CPU demand represents the core demand before applying a utilization target or extra capacity buffer.
Recommended total cores is a planning estimate for experiment-serving application CPU capacity after the selected adjustments.
Estimated cores per variant assumes an even traffic split and is most relevant when variants have separate CPU allocations.
If measured CPU time differs by variant, calculate each variant separately instead of relying on an even split.
Assumptions & Important Notes
- Examples treat CPU time per request as CPU processing work and exclude most external waiting time.
- All variants are assumed to receive equal traffic and have similar CPU cost unless the scenario states otherwise.
- Request rates are treated as evenly distributed within the estimated peak period.
- Results use whole-core rounding and do not include capacity for separate infrastructure components.
Related Examples
Frequently Asked Questions
Why can a small A/B test still show a one-core requirement?
The formula rounds the final capacity up to a whole core. Separate containers or services may also have minimum CPU allocations regardless of calculated load.
Can I use different CPU times for control and treatment?
Yes. When variants have materially different CPU costs, estimate their peak traffic and CPU demand separately, then assess the combined and individual allocations.
What happens if I increase test traffic from 25% to 50%?
With other inputs unchanged, the experiment request rate and raw CPU demand double. The rounded final result may not double exactly.
Does more headroom always produce more cores?
It increases the unrounded capacity estimate. Whether the displayed whole-core result changes depends on where the estimate falls relative to the next whole core.
Should I use average or peak CPU time per request?
Use a representative measured CPU time for the workload expected at peak, and test sensitivity if CPU time changes with payload, cache behavior, or feature usage.
Ready to calculate your own result?
Use the live calculator with your own inputs, timing, and preferences.