直播 APP 后端性能测试思路
原创发布：https://www.cnblogs.com/huanghaopeng/
作者信息：HHP
一、概述
直播 APP 场景中通常包含主播（+辅麦主播）、粉丝 2个主要角色
- 主播主要的交互以推流为主，粉丝主要的交互以拉流为主
- 另外包括粉丝与主播之间的互动，文本消息、表情、送礼物
直播的中的用户核心性能体验为：主播与粉丝之间的交互延迟，而推流是直播第一步，如果推流不稳定，无论如何优化体验都会非常差。
二、性能需求
| 关键角色 | 性能体验 |
|---|---|
| 用户视角 | 第一个画面加载延迟（首次缓冲）、直播画面延迟、卡顿、弱网体验、流量消耗 |
| 运维视角 | CDN、带宽开销、核心业务的横向扩容能力、（政策原因）对流媒体进行存储产生的存储空间开销 |
| 开发视角 | 延迟和卡顿的平衡（客户端缓存） |
| 运营视角 | / |
三、测试实现
1）通讯协议
推、拉流的通讯
- 网络层：Socket 或 St 负责传输
- 协议层：RTMP 或 HLS 负责网络打包（主播连麦：WebRTC）
- 封装层：flv、ts 负责解码数据封装
- 编码层：h.264、acc 负责图像、音频压缩
非推、拉流的通讯
- HTTP、WebSocket
2）测试工具
| 工具 | 支持协议 | 说明 |
|---|---|---|
| St-load | RTMP | （Linux）通过模拟并发的推拉流实现特定负载的测试 |
| Locust | 自带 HTTP Client，其它协议需自行实现 Client | 采用（单进程）协程+IO复用实现并发负载 |
四、测试策略
说明：直播类压测的核心是验证并发下推、拉流的顺畅，是协议层的测试。用户体验的关键是和主播之间的交互延迟。
1）核心角色与业务
- 主播 - 直播 - 抓流/推流
- 主播 - 互动 - 查看/回应粉丝的互动
- 粉丝 - 直播 - 切换直播间
- 粉丝 - 直播 - 拉流
- 粉丝 - 互动 - 评论、打赏等互动行为
2）测试用例编写参考
- 参考上条，略
3）测试场景设计关注点
1、性能基准
建立性能基准
- 对 并发推流 进行测试
- 对 并发拉流 进行测试
- 对 粉丝 进入直播间 的首次缓冲延迟（包括：首包用时延迟、视频首帧延迟） 进行测试
- 对 特定的 码率、帧率 所对应带宽开销进行测试
- 对并发 进入直播间 时的内容交互加载延迟进行测试
- 直播间中的主播与粉丝交互延迟
- 对 弱网环境 进行不同程度的并发测试
2、负载测试
- 关注 日度 业务峰值负载（业务量、时间、时长）
- 关注 周/月 中业务峰值负载（业务量、时间、时长）
- 关注 运营推广 过程中所涉及的业务负载（业务量、时间、时长）
- 关注 意外负载 的出现时机、负载特点
3、容量测试
- 基于“性能基准”结果，参考：1000 - 2000 - 3000 - XXXX 的方式进行主播递增推流测试
- 关注 良好性能体验 条件下的最高支持在线主播数量
- 关注 可容忍上限 条件下的最高支持在线主播数量
- 关注 系统资源充裕 条件下的最高在线主播数量
- 关注 系统资源不足 条件下的最高在线主播数量
4、可用性测试
- 以施加峰值负载的方式达到考核时间周期的业务量
5、可靠性测试
- 关注 网络异常 / 弱网环境 对性能基准的影响
- 关注 服务异常 对性能基准的影响
- 关注 冗余节点 随机的上、下线对性能基准的影响
- 关注 冗余节点 随机的上、下线对：功能可用性、事务性、性能、持久化设计 的影响
6、资源规划 / 扩容配置
- 关注核心业务在性能上横向扩容过程中，节点增加与性能削减的关系
- 关注主播推流对服务产生的存储空间占用开销
- 关注主播推流对服务产生的带宽占用开销
4）测试场景设计
（参考产品设计 与“测试场景设计关注点”：略）
| 测试场景 | 场景描述 | 场景目标 | 执行策略 | 期望结果 |
|---|---|---|---|---|
| 性能基准测试 | ||||
| 负载测试（推、拉流） | ||||
| 负载测试（HTTP、WS流） | ||||
| 容量测试 | ||||
| 可用性测试 | ||||
| 可靠性测试 | ||||
| …… |
五、备注
- 脚本需要实现粉丝端首次缓冲时间的延迟测试，即对首包、首帧画面的断言、延迟、丢帧判断测试。