A/B Testing CPU Requirement Formula
Learn how to estimate total CPU cores and CPU capacity per concurrent user for an A/B test.
This calculation translates concurrent A/B test traffic and CPU work per request into planned CPU capacity. It includes a utilization target so the estimate leaves headroom instead of assuming servers can run continuously at full CPU use.
- 100% Free
- No Sign-Up Required
- Private & Secure
- Mobile Friendly
Estimated CPU Cores Required
Where:
First, calculate the total requests per second. Multiply that by the CPU time needed for each request, convert milliseconds to seconds, and divide by the planned CPU utilization.
Variables Explained
| Variable | What It Means | Unit |
|---|---|---|
| concurrentUsers - Concurrent users | The expected number of active users at the same time during the test period. | users |
| requestsPerUserMinute - Requests per user per minute | Average application requests made by one active user each minute. | requests/minute |
| baselineCpuMsPerRequest - Baseline CPU time per request | Average CPU processing time for an application request before experiment processing. | ms/request |
| experimentOverheadMs - Experiment overhead per request | Additional CPU time for assignment, flags, analytics, or variant-specific processing. | ms/request |
| targetCpuUtilization - Target CPU utilization | Planned average percentage of available CPU capacity to use. | percent |
| variantCount - Number of variants | Total equally split variants, including the control, used to estimate users per variant. | variants |
Step-by-Step Calculation
Calculate total requests per second
Convert the per-user request frequency into the total request rate generated by all concurrent users.
requestsPerSecond = concurrentUsers * requestsPerUserMinute / 60
Calculate CPU time per test request
Add normal application CPU processing and the extra work introduced by the experiment.
cpuMsPerRequest = baselineCpuMsPerRequest + experimentOverheadMs
Convert request work into CPU seconds per second
This is the CPU work the application needs each second before capacity headroom is applied.
cpuSecondsPerSecond = requestsPerSecond * cpuMsPerRequest / 1000
Apply the utilization target
Divide workload by the usable share of each core to estimate planned total CPU capacity.
cpuCoresRequired = cpuSecondsPerSecond / (targetCpuUtilization / 100)
Calculate CPU capacity per concurrent user
Divide total planned cores by concurrent users to show average capacity attributable to one active user.
cpuPerUser = cpuCoresRequired / concurrentUsers
Estimate users per variant
Split concurrent users evenly across variants for a simple traffic-distribution estimate.
usersPerVariant = concurrentUsers / variantCount
Example: 10,000 concurrent users in a two-variant test
Total request rate
10,000 × 6 ÷ 60
1,000 requests/second
CPU time per test request
20 + 5
25 ms/request
CPU work per second
1,000 × 25 ÷ 1,000
25 CPU seconds/second
Planned CPU capacity
25 ÷ 0.70
35.71 cores
CPU capacity per user
35.71 ÷ 10,000
0.003571 cores/user
Users per variant
10,000 ÷ 2
5,000 users per variant
Final Result
Estimated capacity is 35.71 CPU cores, or 0.003571 cores per concurrent user, at a 70% CPU utilization target.
Assumptions
- ✓Concurrent users generate requests at the stated steady average rate.
- ✓The supplied CPU milliseconds per request represent CPU time rather than total request latency.
- ✓Traffic is evenly distributed across variants for the users-per-variant output.
- ✓One CPU core provides approximately one CPU second of processing capacity per second.
- ✓The utilization target represents the planned usable portion of available CPU capacity.
Limitations
- !Request CPU time can vary substantially by endpoint, device, cache state, and variant behavior.
- !The calculation does not include separate capacity for databases, memory, network bandwidth, storage, or third-party services.
- !Autoscaling delays, node failures, background jobs, and operating system overhead are not separately modeled.
- !Uneven assignment, bot traffic, bursts, and event logging spikes can make real CPU use differ from the average estimate.
Common Mistakes to Avoid
Using average daily users instead of peak concurrent users.
Entering end-to-end response time as CPU time when much of the delay is database or network waiting.
Omitting CPU used by feature flags, exposure logging, analytics events, and variant-specific code.
Treating 100% utilization as safe production capacity rather than allowing operational headroom.
Assuming additional variants automatically increase total CPU demand when total traffic and per-request work remain unchanged.
Rounding the capacity estimate down before considering available instance or container sizes.
Related Formulas
Frequently Asked Questions
How is CPU required for an A/B test calculated?
Multiply total requests per second by combined CPU milliseconds per request, divide by 1,000, then divide by the target utilization as a decimal.
What is CPU cores per concurrent user?
It is total planned CPU cores divided by concurrent users. It is useful for comparing the relative CPU intensity of different workloads or experiment designs.
Does a higher number of variants increase CPU requirements?
Not by itself when total traffic and per-request CPU work stay constant. It can increase CPU use if more variants add more decision logic, assets, logging, or processing.
Why does target CPU utilization affect required cores?
A lower target means each core is planned to carry less average load, so more total cores are needed to provide headroom for changes in demand and processing time.
Should I use CPU time or request latency in the formula?
Use CPU time. Request latency may include waiting on databases, networks, queues, or external services that does not consume application CPU continuously.
Ready to calculate your result?
Use the calculator to get instant results with your own inputs.