GB/T 28181 · LOAD TEST
国标28181 平台压测：从 100 台到 1 万台的实操路径
「这台服务器能接多少路」没有标准答案，只有在你这份配置、这个码率、这套网络下测出来的答案。压测的价值不是跑出一个漂亮的数字，而是知道失败从第几台开始、卡在哪一步。
压测要回答的三个问题
- 容量上限在哪：一路一路加上去，从哪一台开始掉？
- 爬坡会不会雪崩：设备是分批上线还是一起上线，平台的 SIP 线程池、连接数够不够？
- 失败卡在哪一步：注册被拒、INVITE 超时、还是注册成功但媒体没到？这三种失败的修法完全不同。
只回答第一个问题的压测，通常会得出「能接 3000 路」这种结论，然后上线第一天在 800 路就挂掉。
先定指标，再动手
| 指标 | 怎么看 | 出现什么值说明有问题 |
|---|---|---|
| 注册成功率 | 离线设备数 ÷ 发起数 | 随路数上升而下滑，说明不是网络抖动而是瓶颈 |
| 注册 TPS | 每秒完成的注册数 | 长时间压在低位、队列越积越长，说明单线程或锁竞争 |
| 点播成功率 | INVITE 后收到 200 OK 并有首帧 | 注册全绿但点播失败，问题在媒体侧不在信令侧 |
| 首帧时间 | 下发 INVITE 到出画面 | 超过 3 秒，用户会认为「点了没反应」 |
| 失败原因分布 | 按 SIP 状态码与超时归类 | 集中在 408 / 超时，先查网络与线程池；集中在 403，查密码与白名单 |
平台侧还要同步看 CPU、内存、文件句柄数、媒体节点带宽——单看信令成功率会漏掉媒体节点的瓶颈。
四段式压测法
| 阶段 | 目的 | 建议做法 |
|---|---|---|
| 1. 基线 | 拿到「肯定没问题」的参照值 | 100 台，匀速注册，跑 10 分钟，记录全部指标 |
| 2. 爬坡 | 找出拐点 | 每 30 秒加一批，直到成功率跌破 99% 或 TPS 不再增长 |
| 3. 稳态 | 排除「撑得住一秒、撑不住十分钟」 | 停在拐点的 80%，连续跑 30 分钟以上 |
| 4. 混合 | 接近真实业务 | 打开真推流占比，叠加点播、回放、云台控制 |
第 4 段最容易被跳过，但它最接近上线后的实际负载：注册只是入场，真正的压力来自同时取流和点播。
五个最容易踩的坑
- 端口没开够。UVP-GB28181 的独立部署包使用连续的
51000–51064一段端口，SIP 与媒体都要走这一段；只放行了 5060 就开工，表现是「注册成功、点播黑屏」。启动时平台会逐个实测端口，被占用会当场报错。 - 压测机自己先趴了。1 万台虚拟设备对发起端同样是重负载。看到平台 CPU 只有 20% 而成功率暴跌，先看压测机的 CPU 和网络队列。
- 全用假流。只注册不推流，测出来的是信令容量，不是媒体容量。真实容量由「同时取流的通道数 × 码率」决定，跟注册数不是一回事。
- 文件句柄与连接数上限。
ulimit -n默认 1024 的机器，接不到 1000 路就会开始随机失败，而且报错信息完全不像「句柄不够」。 - 只看总成功率不看时间分布。前 10 分钟 100%、后面掉到 90%，平均值仍然是 95%，但用户感知是「用着用着就断了」。
用 UVP 桌面端跑一轮的步骤
- 在平台侧确认 SIP 地址、端口、域、注册密码，并放行
51000–51064。 - 桌面端填好这四个参数，设虚拟设备数量（上限 10000）、爬坡速率和媒体档位。
- 先跑 100 台确认链路通，再按上面的四段法加量。
- 压测过程中看实时的成功率与 TPS，失败时展开 SIP 报文，看是哪个状态码。
- 导出报告，把配置、路数、成功率、失败分布一起存档——下次换机器时这就是对比基线。
平台要多大配置，可以先用资源测算按路数、码率、录像天数估一遍，再拿压测结果校准。
常见问题
1 万台是桌面端的上限，还是平台的上限
1 万台是模拟器单机可以拉起的虚拟设备数，不是平台的容量承诺。平台容量取决于服务器规格、码率、是否同时取流，必须实测。
能不能压别人家的国标平台
可以。走的是标准 SIP 注册与点播流程，不绑定 UVP 自己的平台；对方平台只要支持 GB/T 28181，填上它的四个参数就能压。
压测需要多大带宽
按「同时取流通道数 × 码率」估算。以 720P、2 Mbps 为例，500 路并发取流需要约 1 Gbps 上行。只做注册压测时带宽需求可以忽略，但那样测不出媒体瓶颈。
报告里最该看哪一栏
失败原因分布。成功率告诉你「有没有问题」，失败分布告诉你「问题在哪一层」。