Bandwidth Calculator for Load Tests and APIs

Bandwidth = requests per second × bytes per response × 8. At 500 RPS with 50 KB responses plus about 5% for headers and TLS, a server sends 500 × 52,500 bytes = 26.25 MB/s, which is 210 Mbps, 94.5 GB per hour and 15.75 GB in a 10-minute load test. The calculator below converts your RPS and payload sizes into Mbps or Gbps, data volume per test, hour and month, and an egress cost at the $/GB price you enter.

The bandwidth formula

Throughput in bits per second is a unit conversion on top of request rate. The calculator uses decimal units throughout (1 KB = 1,000 bytes, 1 GB = 10^9 bytes, 1 Mbps = 10^6 bits/s), which is how network links are rated:

bytes_per_response = response_KB × 1,000 × (1 + overhead%)
egress_bytes/s     = RPS × bytes_per_response × (1 − CDN_offload%)
egress_Mbps        = egress_bytes/s × 8 / 1,000,000
ingress_Mbps       = RPS × request_KB × 1,000 × (1 + overhead%) × 8 / 1,000,000

GB_per_test        = egress_bytes/s × test_seconds / 10^9
GB_per_hour        = egress_bytes/s × 3,600 / 10^9
GB_per_month       = avg_RPS × bytes_per_response × (1 − CDN%) × 2,592,000 / 10^9   (30 days)
cost               = GB × your $/GB

Response size dominates for almost every web workload. Requests are usually a few hundred bytes to a few KB of headers, cookies and JSON, so ingress is a small fraction of egress unless you are testing uploads.

Cloud bills sometimes use GiB (2^30 bytes). A GiB is about 7.4% larger than a GB, so a bill in GiB shows a slightly smaller number for the same traffic.

Worked example

An illustrative JSON API, the calculator's defaults:

1. Bytes per response: 50 KB × 1.05 = 52,500 bytes.
2. Egress at 500 RPS: 500 × 52,500 = 26.25 MB/s = 210 Mbps.
3. Ingress: 500 × 2,100 bytes = 1.05 MB/s = 8.4 Mbps.
4. Per 10-minute test: 26.25 MB/s × 600 s = 15.75 GB.
5. Per hour at peak: 26.25 MB/s × 3,600 s = 94.5 GB.
6. Per month at an average of 100 RPS: 100 × 52,500 × 2,592,000 s = 13,608 GB, about 13.6 TB.

Enter your provider's internet egress price to see cost. The field is blank on purpose: prices differ by provider, region, tier and destination, and many providers bill in tiers that get cheaper with volume. The placeholder is only an example, not a quoted price.

Where to get realistic payload sizes

For a mixed workload, compute a weighted average: Σ(share_i × size_i). Three endpoints at 70% × 4 KB, 25% × 30 KB and 5% × 400 KB average 2.8 + 7.5 + 20 = 30.3 KB, and the rare large response contributes two thirds of the bandwidth.

Compression changes the answer more than anything else

Text payloads such as JSON, HTML, CSS and JavaScript compress well with gzip or Brotli, often to a fraction of their original size. Images, video and archives are already compressed and barely shrink. Two traps follow for load tests:

• The load generator must ask for compression. Servers only compress when the request carries Accept-Encoding: gzip, br (or similar). Browsers always send it; some load testing tools and scripts do not by default. If yours does not, add the header explicitly, or the test will move several times more bytes than real users do.
• Compression costs CPU. Compressing dynamic responses at high RPS is real work. A test without compression understates CPU and overstates bandwidth; a test with it shows both correctly. nginx's gzip_comp_level defaults to 1, which favors speed over ratio.

# nginx: compress text responses, skip tiny ones
gzip on;
gzip_types application/json text/css application/javascript text/plain;
gzip_min_length 1024;
gzip_comp_level 5;

CDN offload and what your origin actually sends

A CDN serves cached responses from its edge, so only cache misses travel from your origin. The "CDN offload" input is the share of response bytes served from cache. At 90% offload the origin in the example sends 21 Mbps instead of 210 Mbps, and monthly origin egress drops from 13.6 TB to 1.36 TB (the CDN bills its own delivery separately).

Decide which of the two you are testing. A test that goes through the CDN with a warm cache mostly measures the CDN. A test aimed at the origin, with cache-busting or a direct origin hostname, measures your servers and the full egress. Load testing behind Cloudflare covers how to do either deliberately.

Load tests cost egress too

Every response your servers send to a load generator is billable egress, the same as a real user's. Budget for it before a long or repeated test:

Bandwidth also limits the test itself. If the generator side or a NAT gateway on your side cannot carry the throughput, latency rises for reasons unrelated to your application. A hosted service such as LoadTester runs the workers for you, but your origin's uplink, load balancer and any NAT or firewall still have to carry every byte. Check the link capacity against the peak number above before blaming the app for latency that rises under load.

Checklist

1. Get the weighted average transferred response size per request from logs or DevTools.
2. Confirm the load test sends Accept-Encoding like real clients.
3. Decide whether you are testing through the CDN or the origin, and set offload accordingly.
4. Compare peak Mbps against the origin uplink, load balancer and NAT limits.
5. Price the test and the monthly traffic with your own $/GB, then size the test with the RPS calculator and the instance count with the server capacity calculator.