A/B Testing CPU Requirement (Annual) Calculator
Estimate the annual CPU hours and average active CPU capacity needed to run server-side A/B tests from traffic, test duration and processing time.
Overview
Use this A/B testing CPU requirement calculator to estimate the annual compute time added by server-side experiment processing. Enter your annual visitor volume, eligible request activity, test traffic share, typical test duration, testing frequency and measured or estimated CPU time per tested request.
How it works
The calculator estimates the request volume in one experiment by applying the test traffic allocation and test duration to annual visitor activity. It multiplies those requests by the CPU time used for each tested request, then converts the result into CPU hours. Annual CPU hours are calculated by multiplying the average per-test CPU hours by the number of tests planned. The active CPU-core figure spreads one test's CPU seconds across its running time, so it is an average rather than a peak requirement.
How to use this calculator
- 1Enter the expected number of visitors over a full year.
- 2Add the average number of requests per visitor that will use experiment logic.
- 3Set the percentage of traffic included in a typical test.
- 4Enter the usual test duration and number of tests planned each year.
- 5Add the number of variants and CPU milliseconds used per tested request.
- 6Review the annual CPU hours and average active CPU capacity estimates.
Example Calculation
Annual visitors
1200000
Tested requests per visitor
8
Traffic allocated to tests
50%
Average test duration
28
Tests per year
12
Variants per test
2
CPU time per tested request
50
Estimated annual CPU requirement
61.37 CPU hours
With 1.2 million annual visitors, eight tested requests per visitor, 50% test traffic and twelve 28-day tests, the estimated experiment workload is about 61.35 CPU hours per year, or about 5.11 CPU hours per test.
Frequently asked questions
What is an A/B testing CPU requirement?
It is the CPU processing time used by experiment-related work, such as variant assignment, feature evaluation, event logging and request handling during A/B tests.
Does adding more variants increase total CPU usage?
Not necessarily. When each request is assigned to one variant, total tested traffic stays similar and is divided among variants. More complex evaluation or logging may still increase CPU time per request.
Why does the calculator use CPU milliseconds per request?
Experiment processing is usually performed on individual requests. Measuring or estimating CPU time per request lets you scale the workload using expected experiment traffic.
Is average active CPU capacity the same as server size?
No. It is an average CPU-core estimate during a test. Production capacity should also account for traffic spikes, other workloads, redundancy, utilization limits and scaling policy.
How can I find CPU time per tested request?
Use application profiling, tracing or infrastructure metrics to compare CPU usage with and without the experiment path under representative traffic. If this is unavailable, start with a conservative estimate and validate it in testing.
Does this include database and analytics costs?
No. The calculation covers the entered CPU processing time only. Database queries, event pipelines, storage, network transfer and third-party experimentation charges should be estimated separately.
Explore Related Calculators
Assumptions and warnings
Assumptions
- Traffic is spread evenly throughout the year and across each test's active days.
- Each test uses the stated share of eligible traffic for its full duration.
- The CPU time per request includes the experiment-related work you want to measure, such as assignment, evaluation and logging.
- Variants divide experiment traffic but do not multiply total visitor requests, because each request is normally assigned to one variant.
- The estimate measures CPU processing time only and excludes storage, network, database, queueing and fixed infrastructure costs.
Warnings
- This is a capacity-planning estimate, not a guarantee of production infrastructure requirements.
- Allow additional headroom for traffic peaks, retries, concurrent experiments, failover and other application workloads.