> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# RUM 上报带宽估算与容量规划

> 在接入 RUM 前估算上报流量需要多少带宽：从用户规模换算到带宽档位的三步方法、实测参考参数、降低带宽的手段与实测校准方式。

接入 RUM 后，终端用户的监控数据会持续上报到接收端。对于需要提前采购带宽或规划私有化部署链路容量的团队，本文给出一套可代入自己业务参数的估算方法，以及基于真实应用实测的参考值。

## 估算方法：分三步走

带宽估算分三步，每一步的确定性不同，建议分开计算而不是直接套一个总数：

| 步骤 | 换算 | 确定性 |
| - | - | - |
| 1 | 带宽 → 事件/秒 | 高。只取决于单事件体积和是否压缩 |
| 2 | 事件/秒 → 并发用户 | 中。随应用类型有 10 倍以上差异 |
| 3 | 并发用户 → 日活 | 低。取决于人均在线时长与业务峰谷比 |

### 基准参数（实测参考值）

以下参数在真实 Web 应用上实测得出，可直接作为估算起点：

| 参数 | 参考值 | 说明 |
| - | - | - |
| 单事件原始体积 | 约 1.9 KB | 含会话、页面、设备等公共上下文 |
| 单次上报请求 | 约 15 KB | 一个批次约 8 个事件 |
| 批量触发阈值 | 16 KiB / 50 条 / 30 秒 | 任一条件满足即发送 |
| 压缩比 | 约 6.8 : 1 | deflate，回放与常规事件两类数据实测一致 |
| 事件构成 | resource 约 72%，long task 约 22% | 事件量主要由页面网络请求数驱动 |

### 第一步：带宽 → 事件/秒

单事件 1.9 KB，开启压缩后约 0.28 KB：

| 带宽 | 不开压缩 | 开启压缩 |
| - | - | - |
| 10 Mbps | 约 660 事件/秒 | 约 4,500 事件/秒 |
| 20 Mbps | 约 1,300 | 约 9,000 |
| 50 Mbps | 约 3,300 | 约 22,500 |
| 100 Mbps | 约 6,600 | 约 45,000 |

换算公式：`带宽(Mbps) × 1000 ÷ 8 ÷ 单事件 KB = 事件/秒`

### 第二步：事件/秒 → 并发用户

每个活跃用户产生事件的速率随应用类型变化很大：

```text theme={null}
每用户事件率 ≈ 每次页面浏览的事件数 ÷ 页面平均停留秒数
```

| 应用类型 | 事件率（事件/秒/用户） | 说明 |
| - | - | - |
| 长驻单页（WebSocket 通信） | 约 0.1 | 消息收发不产生事件，见下文 |
| 控制台 / 后台管理 | 约 0.2 | 实测值 |
| 一般 Web 应用 | 约 0.5 | 推算值 |
| 内容 / 电商（高频导航） | 约 1.3 | 推算值 |

以「开启压缩 + 一般 Web 应用」为例：10 Mbps ÷ 0.5 事件/秒 ≈ **9,000 并发用户**。

<Note>
  事件率取决于**网络传输方式**，而不是业务繁忙程度。SDK 只对 `XMLHttpRequest` 和 `fetch` 插桩，不追踪 WebSocket，也不记录键盘输入。因此 WebSocket 高频收发消息**不产生任何事件**；反之，HTTP 短轮询每次轮询都是一个 resource 事件（3 秒轮询 = 每用户 +0.33 事件/秒）。估算前先确认应用的数据通道类型。
</Note>

### 第三步：并发用户 → 日活

```text theme={null}
日活 = 峰值并发 × 86400 ÷（人均每日在线秒数 × 峰值系数）
```

* **人均每日在线秒数**：后台类应用可达 3,000 秒以上，面向公众的应用通常低得多
* **峰值系数**：业务时段集中度，一般取 3 \~ 5；业务高度集中（考试、抢购类）可达 8 以上

这一步没有通用值，务必代入自己的业务数据。

## 影响带宽的两个关键开关

### 上报压缩（Web 端默认关闭）

浏览器 SDK 的 `compressIntakeRequests` 默认关闭，开启后带宽降至约 1/6.8，且没有数据损失：

```js theme={null}
flashcatRum.init({
  // ...
  compressIntakeRequests: true,
});
```

这是所有降带宽手段里唯一零代价的一项，建议始终开启。移动端（Android / iOS / HarmonyOS）SDK 默认已开启压缩，无需配置。

### 会话重放（默认关闭）

会话重放的数据量与常规事件不在一个量级：实测约为常规 RUM 事件总量的 **20 \~ 30 倍**，具体取决于页面 DOM 变更频率。启用重放前建议先对小比例会话开启，实测一天后再确定采样率，不要直接套用倍数估算。详见[会话重放](/zh/rum/session-replay/overview)。

## 移动端与 Web 的差异

移动端不能直接套用 Web 参数，人均带宽成本约为 Web 的 1/20：

| | Web 浏览器 SDK | Android / iOS / HarmonyOS SDK |
| - | - | - |
| 上报压缩默认值 | 关闭（需手动开启） | **默认开启** |
| 单事件原始体积 | 约 1.9 KB | 约 1.2 KB |
| resource 事件来源 | 页面全部静态资源 + XHR/fetch | 仅 App 主动发起的 API 请求 |

混合客户端（Web + App）应分端估算后相加，不要用统一事件率。

## 降低带宽的手段

按性价比排序：

| 手段 | 效果 | 代价 |
| - | - | - |
| 开启上报压缩（Web） | 降至约 1/6.8 | 无 |
| 降低[会话采样率](/zh/rum/best-practices/sampling) | 线性下降 | 长尾问题复现能力下降 |
| 关闭资源采集（`trackResources: false`） | 降至约 1/3.6 | 失去接口与静态资源性能数据 |
| 过滤第三方域名资源 | 视页面构成而定 | 通常无损 |
| 关闭长任务采集（`trackLongTasks: false`） | 降至约 1/1.3 | 失去主线程阻塞分析 |

## 私有化部署：两段链路的容量关系

私有化部署常见「公网接入机 + 内部机房」两段链路。若接入层为 nginx `proxy_pass` 透传（不解压、不解析），两段的字节数基本相等，**容量按同一个数字准备**；客户端压缩一次配置即同时降低两段。

接入层三项常见配置检查：

1. **上游连接复用**：`upstream` 配置 `keepalive`，并设 `proxy_http_version 1.1`、清空 `Connection` 请求头，避免跨机房每请求重建连接
2. **请求体上限**：`client_max_body_size` 默认 1 MB，会话重放分片与 SourceMap 上传会超出触发 413，建议调至 20 MB 以上
3. **回程流量**：上报响应约 0.4 KB/请求，开启压缩后约为入方向的 18%，出方向计费的链路不宜忽略

## 用实测校准估算

上文参数是通用参考值，正式采购前建议用两种方式之一校准：

* **灰度外推（推荐）**：对 1% 用户开启采集运行一天，读取入口实际流量后线性放大，误差通常在 20% 以内
* **单请求实测（快速）**：开发者工具中过滤上报域名，读取请求头的 `Content-Length`（注意 Network 面板 Size 列显示的是响应体积，不是上传体积），结合请求频率推算

<Note>
  表中数值为估算参考，用于确定采购档位与容量规划，不构成服务等级承诺。实际用量以校准结果为准。
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.