Optimizing CDN Bandwidth Utilization and Cost Reduction with Predictive Control (Yugong Platform)

As the scale of content distribution grows, enterprises increasingly rely on CDN bandwidth. In China, CDN providers charge based on peak bandwidth, so reducing peak usage directly lowers costs. This article shares the author’s practical experience in cutting CDN costs by improving bandwidth utilization and implementing predictive control.

Background : After the rapid expansion of the Internet, many companies face a slowdown in business growth and focus on internal cost reduction. The “cost‑saving and efficiency‑enhancing” mindset drives technical teams to analyze cost‑related business flows and seek technical solutions.

Glossary :

CDN: Content Delivery Network (static CDN is the focus of this article).

CDN bandwidth utilization = actual bandwidth / billed bandwidth.

"Yugong Platform": a platform that predicts bandwidth and performs peak‑shaving/valley‑filling to improve overall CDN utilization.

2. Finding Cost‑Saving Opportunities

CDN billing in China follows a “peak‑average” model: the daily maximum is recorded, and the monthly charge is the average of daily peaks. Lower daily peaks mean lower costs.

The cost‑saving process is divided into three stages:

Local optimization : Identify the six core business services (app store distribution, game center, OTA, etc.) that consume >90% of CDN bandwidth. Set utilization targets for each service and drive improvements.

Global optimization : Separate a portion of bandwidth that can be controlled (e.g., licensed WLAN download bandwidth). Use historical trends to set hourly thresholds and apply a token‑bucket algorithm to smooth peaks and fill valleys.

Automation : Replace manual adjustments with programs. Apply machine‑learning‑based prediction to forecast bandwidth and automatically adjust the token‑bucket parameters.

3. Predictive Modeling

The prediction workflow consists of two phases:

Observation → Analysis → Modeling : Feature extraction and analysis of historical bandwidth patterns.

Algorithm simulation → Validation : Test several algorithms and select the one that meets accuracy requirements.

Key prediction components:

Threshold prediction : Prophet is used to forecast daily bandwidth thresholds because of its strong time‑series handling and ability to detect sudden changes.

Real‑time bandwidth prediction : A custom algorithm combines recent data (e.g., 15‑minute‑old measurements) with historical trends to produce short‑term forecasts.

Model splitting : The final model focuses on threshold time‑series prediction and real‑time bandwidth forecasting, using residual analysis and time‑series fitting.

4. Implementation Details

The overall solution aims to lower the billed bandwidth by predicting the peak line (blue) and controlling the shaded area (actual usage) beneath it.

Yugong Platform workflow:

Offline model predicts the next‑day threshold.

Real‑time model predicts short‑term bandwidth.

Combine threshold and prediction to compute a control value.

Write the control value into a token‑bucket; tokens are generated per second for downstream consumption.

4.2.1 Threshold prediction with Prophet

Prophet’s time‑series characteristics and change‑point detection fit the CDN bandwidth scenario, achieving high accuracy for most threshold points.

4.2.2 Custom bandwidth prediction algorithm

The algorithm uses recent bandwidth, historical trends, and a weekly cycle to fit future bandwidth values.

4.2.3 Sub‑models for control conversion

These handle the conversion from predicted bandwidth to actionable control parameters, addressing spikes, boundaries, and interventions.

4.2.4 Flow‑control SDK

A unified SDK implements a token‑bucket mechanism to control bandwidth across multiple services. The core Lua script used in Redis is shown below:

//初始化和扣减CDN流量的LUA脚本
// KEY1 扣减key
// KEY2 流控平台计算值key
// ARGV1 节点个数 30 整形
// ARGV2 流控兜底值MB/len 提前除好(防止平台计算出现延迟或者异常，设一个兜底值)，整形
// ARGV3 本次申请的流量（统一好单位MB，而不是Mb） 整形
// ARGV4 有效期 整形
public static final String InitAndDecrCdnFlowLUA =
        "local flow = redis.call('get', KEYS[1]) " +
                "//优先从控制值里取，没有则用兜底值"
                "if not flow then " +
                "   local ctrl = redis.call('get', KEYS[2]) " +
                "   if not ctrl then " +
                "//兜底"
                "       flow = ARGV[2] " +
                "   else " +
                "       local ctrlInt = tonumber(ctrl)*1024 " +
                "//节点个数"
                "       local nodes = tonumber(ARGV[1]) " +
                "       flow = tostring(math.floor(ctrlInt/nodes)) " +
                "   end " +
                "end " +
                "//池子里的值"
                "local current = tonumber(flow) " +
                "//扣减值"
                "local decr = tonumber(ARGV[3]) " +
                "//池子里没流量，返回扣减失败"
                "if current <= 0 then " +
                "    return '-1' " +
                "end " +
                "//计算剩余"
                "local remaining = 0 " +
                "if current > decr then " +
                "    remaining = current - decr " +
                "end " +
                "//执行更新"
                "redis.call('setex', KEYS[1], ARGV[4], remaining) " +
                "return flow";

4.4 Technical Issues

Hotspot key problem : Distribute keys across Redis nodes using prefixes to avoid single‑node overload.

Local cache : When the token bucket is empty, a local cache key prevents excessive Redis calls.

Large file control : Split large files or use coarse‑grained control for files that take a long time to download.

Traffic conversion factor : Adjust for the difference between allocated bandwidth and actual traffic.

Boundary and burst handling : Special rules for midnight billing boundaries, weekend/holiday patterns, and unexpected spikes.

5. Final Results

After deploying the Yugong Platform, the CDN bandwidth utilization increased significantly, as shown by the before‑and‑after charts.

Conclusion

Selected CDN cost reduction as the research direction.

Used Prophet for offline threshold prediction.

Developed a custom real‑time prediction algorithm.

Continuously refined the model to handle bursts, holidays, and other edge cases.

Achieved substantial cost savings for the company.