How to size bandwidth for a CDN origin
Size the origin for what the edges fetch during your busiest interval. A million viewers can request the same cached segment without the origin sending a million copies.
BryskBits ·
Calculate origin egress
Enter decimal GB sent by the origin, not the total served to viewers by the CDN.
- Average payload
- 12 Gbps
- Port budget before overhead
- 16 Gbps
Start with bytes, not a cache-hit percentage
Group origin bytes sent into equal intervals, including retries and partial responses. Use egress counters if responses span interval boundaries. A request hit ratio weights a small playlist and a large video segment equally; it cannot tell you the bytes read from origin. Use totals without storing viewer identifiers in your sizing sheet.
Worked example: a release fills several edges
Suppose the origin sends 90 GB in 60 seconds after a release. Multiply GB by eight and divide by seconds: 12 Gbps of average payload. Keeping a quarter of the port free requires 12 ÷ 0.75 = 16 Gbps before overhead. If half those bytes left in ten seconds, that shorter interval alone averaged 36 Gbps. The minute average hides that burst.
Compare normal delivery with a cold-cache window and a node-out scenario. Include other applications on the same interface. Check disk reads separately: a hot OS cache can make a file test look faster than the underlying array. These are planning examples, not BryskBits measurements.
Test the audience path separately
Multiple receiving clients can drive high aggregate throughput while one viewer still stalls. For the origin test, record direction, concurrency, payload, duration and storage state. For playback, record the viewer network, bitrate, startup delay and stalls from a representative device. Keep the results separate.
Use the network test checklist before comparing 40 Gbps configurations and 100 Gbps configurations. For the rules governing cache reuse and revalidation, see RFC 9111: HTTP Caching.