A/B Testing CPU Requirement Formula
Learn how to estimate monthly CPU core-hours and average CPU capacity for A/B test traffic including experiment overhead.
This calculation estimates the application CPU work attributable to requests included in an A/B test. It converts per-request CPU time into monthly core-hours, adds experiment-processing overhead, and expresses the result as an average number of continuously available CPU cores.
- 100% Free
- No Sign-Up Required
- Private & Secure
- Mobile Friendly
Monthly A/B Test CPU Requirement
Where:
First find the requests assigned to the experiment. Multiply those requests by CPU milliseconds per request, convert milliseconds to core-hours, and then add the estimated extra CPU work caused by experimentation.
Variables Explained
| Variable | What It Means | Unit |
|---|---|---|
| monthlyRequests - Monthly requests | Total eligible requests that could reach the tested page, endpoint, or application flow during the month. | requests |
| testTrafficPercent - Traffic included in test | Percentage of eligible monthly requests assigned to the experiment. | percent |
| cpuTimePerRequestMs - Average CPU time per request | Average application CPU time used by one eligible request before experiment-specific processing. | milliseconds |
| experimentOverheadPercent - Experiment CPU overhead | Additional CPU percentage for assignment, flags, logging, analytics, and variant logic. | percent |
| monthHours - Hours in planning month | Number of hours used to convert monthly core-hours into average CPU cores. | hours |
| variantCount - Number of variants | Number of experiment variants including the control, used for the equal-split per-variant output. | number |
Step-by-Step Calculation
Estimate experiment traffic
Only requests assigned to the experiment are included in the CPU estimate.
testRequests = monthlyRequests * (testTrafficPercent / 100)
Calculate base CPU core-hours
There are 3,600,000 milliseconds in one hour, so this converts total CPU milliseconds into CPU core-hours.
baseTestCpuCoreHours = testRequests * cpuTimePerRequestMs / 3600000
Add experiment-processing overhead
This increases base request processing by the estimated CPU cost of experiment-related work.
monthlyCpuCoreHours = baseTestCpuCoreHours * (1 + experimentOverheadPercent / 100)
Find extra CPU from testing
This isolates the incremental CPU core-hours attributed to experiment overhead.
additionalCpuCoreHours = monthlyCpuCoreHours - baseTestCpuCoreHours
Convert to average CPU capacity
This expresses monthly work as average continuously available CPU cores when traffic is evenly distributed.
averageCpuCores = monthlyCpuCoreHours / monthHours
Allocate CPU across variants
This is an even-split planning figure and does not mean every variant necessarily consumes the same CPU.
cpuCoreHoursPerVariant = monthlyCpuCoreHours / variantCount
Example: Two-variant experiment with 50% traffic allocation
Requests in experiment
1,000,000 × (50 ÷ 100)
500,000 requests
Base experiment CPU
500,000 × 25 ÷ 3,600,000
3.47 core-hours
Monthly CPU including overhead
3.47 × (1 + 10 ÷ 100)
3.82 core-hours
Average CPU capacity
3.82 ÷ 730
0.005 CPU cores
CPU per variant
3.82 ÷ 2
1.91 core-hours per variant
Final Result
The experiment is estimated to require 3.82 CPU core-hours per month, equal to about 0.005 average CPU cores, before allowing for peak-load headroom.
Assumptions
- ✓Traffic is spread evenly throughout the planning month when monthly core-hours are converted to average CPU cores.
- ✓The measured CPU time per request represents ordinary application processing before experiment-specific work.
- ✓Experiment overhead reasonably covers assignment, feature-flag evaluation, analytics, logging, and variant logic.
- ✓Variants receive an equal share of test traffic for the per-variant result.
- ✓A CPU core-hour represents one logical CPU core operating for one hour.
Limitations
- !Average CPU capacity does not describe the CPU required during hourly, daily, campaign, or deployment-related peaks.
- !The estimate excludes memory, database, cache, network, storage, queue, and third-party service requirements.
- !CPU time can change with payload sizes, cache hit rates, retries, code paths, and hardware or runtime differences.
- !Variants with materially different rendering or backend behavior may not use equal CPU despite an even traffic split.
Common Mistakes to Avoid
Entering total site requests while also setting test traffic to 100% when only part of the site is eligible for the experiment.
Using wall-clock request latency instead of CPU time per request; waiting on databases or networks is not necessarily CPU work.
Forgetting to include the control when entering the number of variants.
Treating the average CPU-core result as a peak-capacity target.
Using an overhead percentage that omits analytics, logging, feature-flag checks, or variant-specific processing.
Assuming equal per-variant CPU use when one variant performs substantially more work.
Related Formulas
Frequently Asked Questions
How do I calculate CPU core-hours for an A/B test?
Multiply experiment requests by CPU milliseconds per request, divide by 3,600,000, and multiply by one plus the experiment overhead percentage as a decimal.
Why does the formula divide by 3,600,000?
One hour contains 3,600,000 milliseconds. Dividing total CPU milliseconds by that value converts the workload to CPU core-hours.
What does average CPU cores mean in this calculation?
It is monthly CPU core-hours divided by hours in the planning month. It represents an even-load average, not a peak requirement.
Does the number of variants change total CPU core-hours?
Not directly in this model. It divides the total into an equal per-variant figure. Add or increase overhead if more variants create additional processing.
Should experiment overhead be included in CPU time per request?
Use either a baseline CPU time plus separate overhead, or a fully measured experiment CPU time with zero additional overhead. Including both can double-count experiment work.
Ready to calculate your result?
Use the calculator to get instant results with your own inputs.