Skip to content
Calcrivo

Traffic Split Calculator

Calculate the requests-per-second each service version receives under a weighted traffic split, for A/B testing and progressive delivery.

Inputs

requests/sec

Total incoming request rate to be split across versions.

Comma-separated relative weights per version, e.g. '80, 20' for a stable/canary split. Weights need not sum to 100 — they're normalized automatically.

Comma-separated labels matching the order of the weights above (optional, for display only).

Largest Split (RPS)

8,000.0requests/sec

Largest Split Version

stable

Remaining Traffic (RPS)

2,000.0requests/sec

Sum of Weights

100

Step by step

  1. Sum of weights

    80 + 20

    = 100

  2. stable share

    10000 × (80 ÷ 100)

    = 8000.0 req/sec (80.0%)

  3. canary share

    10000 × (20 ÷ 100)

    = 2000.0 req/sec (20.0%)

How it works

Weighted traffic splitting distributes total request volume across service versions proportionally to their configured weights: per_version_rps = total_rps × weight ÷ sum(weights). This is the underlying mechanism behind canary releases, blue-green cutovers and A/B tests in a service mesh — weights don't need to sum to 100, since the router normalizes them, but expressing them as percentages that sum to 100 is the common convention (e.g. Istio VirtualService weight fields).

Formulas

Traffic per version

rps_version = total_rps × weight_percent / 100

total_rps
Total incoming requests per second
weight_percent
Traffic weight assigned to this version (%)

Canary error rate impact

user_facing_error_rate = canary_error_rate × canary_weight / 100

canary_error_rate
Error rate of the canary version
canary_weight
Traffic percentage routed to canary

Frequently Asked Questions

Do traffic split weights have to add up to 100?

No — most service mesh implementations (Istio, Linkerd, various API gateways) normalize whatever weights you provide, so '4, 1' produces the same 80/20 split as '80, 20'. Using percentages that sum to 100 is just a readability convention.

How is this different from a canary deployment rollout?

A canary deployment progressively increases one version's traffic weight over time through several discrete stages; a traffic split is the mechanism used at each stage — this calculator models a single point-in-time split, while the canary deployment calculator models the full staged timeline.

Can I use this for more than two versions?

Yes — provide as many comma-separated weights (and optional labels) as you have versions; the calculator normalizes and splits traffic across all of them, which is useful for multi-variant A/B/n testing.

Does request-level weighting guarantee exact traffic percentages?

Over a large enough sample, yes, assuming random/weighted-random routing; for small request volumes or session-affinity-based routing (sticky sessions), actual observed splits can deviate from configured weights until volume is statistically significant.

You might also need

Related Calculators

Canary Deployment CalculatorBlue-Green Deployment CalculatorService Mesh Overhead Calculator