直播玩法开发者服务器压测工具使用手册
收藏能力申请
- 1.申请条件
- ◦全量上线 90 天内，单日流水峰值大于 50 万的玩法可申请使用。
- ◦申请流程：填下以下问卷进行申请，满足条件后将在 1 个工作日内添加权限。
- 2.获得权限后，可在直播玩法后台 - 开发 - 压测工具中使用。
添加域名
步骤 | 操作 | 示意图 |
第 1 步 | 点击【域名认证】右上角【新增域名】，添加需要认证的域名 |  |
第 2 步 |
| |
第 3 步 |
| |
第 4 步 |
| |
创建压测计划
创建计划
- •压测计划维护着某个压测链路相关的配置信息。
- •点击【压测计划】右上角的【新建计划】按钮，就能新建一个计划，并完成计划信息配置的填写；已创建的计划也能够进行编辑（修改），编辑页面的逻辑与上述相同。
自定义全局变量
文件要求：仅支持CSV文件，编码为utf-8
- •表头是参数名，后续每行是单个请求执行时参数的值
- •压测执行时，会按照环的逻辑依次轮询取值
如配置文件如下，user_id,order_id 1,100, 2,200 3,300则实际执行时，请求的参数值依次为：user_id=1, order_id=100 user_id=2, order_id=200 user_id=3, order_id=300 user_id=1, order_id=100 ...
请求配置
单个计划可支持多个请求，按照串行顺序依次执行，即上一个接口成功返回后才会执行下一个接口，压测请求每次执行都会尝试走完整个流程。
单个请求可直接导入
curl，平台会识别参数，方便编辑。参数提取
请求的返回的参数可以被提取出来，向后续请求传递
- •提取时定义的变量名建议全局唯一，防止冲突
- •目前可以从
header和body中提取，header直接填写参数，body仅支持返回值为json，通过jsonpath语法提取（可参考https://jsonpath.com/）参数注入
语法
${参数名}，会尝试将花括号里的参数进行注入，来源有两部分：全局变量、提取的上下文变量
替换原则：
- •若参数存在即替换为参数值，前后有数据的时候会进行拼接
- •若参数不存在，则保持输入不变
假设当前有一个参数a = 1，则${a}会被替换为1，xx${a}yy会替换为xx1yy需要注意：当入参body为json时，该语法只能位于string字段中•若前后有数据则拼接后最终类型为
string，如"1${a}2"注入后为"112"•否则会被替换为原来的参数类型，如
"${a}"注入后为1
调用检查
自定义配置需要check的返回数据，用于识别压测时非预期的请求。
多个规则按照逻辑与的规则判断，
- 1.必须先判断
HTTP状态码- 2.然后判定业务数据
中途有任意请求检查不通过，则后续的所有请求都不会执行
发压配置
执行时按照配置的梯度进行压测，从初始压并发数/QPS开始，持续一定时间（每阶段持续时间）后，每阶段增加并发数/QPS），梯度上限为最大并发数/QPS。一般用QPS模式。
执行总持续时间后，本次压测完毕。
并发模式
并发模式指的是与服务端建立多个连接，并且在一个连接中发送请求的数量没有限制，这取决于服务端的响应速度，也就是说，服务端延时越低，单位时间内发送的请求数就越大。
请求量：$$qps = 并发数*\frac{1000}{接口耗时（ms）}$$
如 10 并发，会同时有 10 个客户端不断的请求被压接口，收到返回结果后立马开始下一次请求。若服务端处理的时间为 10 毫秒，那 10 并发 1s 就可以发送1000 个请求。
QPS模式
QPS 模式指的是每秒向服务端发送的请求数量，基本上按照压测量级均匀请求。通常会采用此模式进行压测 。
调试执行
以低流量（个位数 QPS）的方式执行计划，若未出现异常报错或超时，则对应的场景链路调试通过。
压测过程中能够实时看到请求状态曲线，涵盖成功 QPS、失败 QPS、接口耗时等。
接口的执行与报错明细汇总在任务最下方。
压测执行
单链路压测
逐个对 2.3 中组织的所有场景进行压测。
每个场景均需执行多轮压测，从相对较低的 QPS 起始，一直到达到目标 QPS，甚至继续冲击更高值。
！在压测开始前务必要调高限流，或者直接去掉限流
压测梯度配置
按照本次要压的 QPS 上限的
40%～50%、增量10%～20%执行。- •单阶段时间固定为
40s，总持续时间做相应计算。- •超时时间统一配置为
10s。以当次400QPS为例，可以按照如下配置
单压测任务通过标准：
- 1.报错率<1%
- 2.耗时没有显著增加，在可接受范围内
- 3.服务各组件负载在安全水位内
执行建议
执行次数 | 最大QPS建议（与目标值的比值） |
1 | 20%～40% |
2 | 50%～80% |
3 | 100% |
4 | 150% |
5 | ...... |
- 1.每次压测完成后，将数据和结论记录到对应轮次场景的表格中。
- ◦若未通过，需补充说明现象，例如：到 XX QPS 时，接口报错/超时。
- 2.若无法达成压测目标，则该场景压测不通过，需进行性能优化后再次压测。将问题记录到报告4.压测问题 &风险记录对应轮次压测中的问题里，并指定处理人。
- ◦若短期内无法完成优化，记录结论，并准备降级预案以应对突发情况。
- 3.若达成压测目标，但在摸高过程中遇到性能瓶颈，可适当调节 QPS，确保能执行通过，得出阈值结论。
举例：假设场景a的压测目标为2000qps，可按照600、1.2k、2k、3k执行压测。•若未达成2k目标，需排查性能瓶颈：
◦如是未加索引这种简单问题，则加索引之后继续压；
◦若需要调整技术方案，则记录问题&原因，指定处理人，下一轮再压；
•若达成2k目标，摸高时不能达到3k，通过调整得到阈值大约为2.6k，记录此阈值；
单场景可能会经历多轮压测，要确认所有场景全部能通过。
压测恢复
压测完成后，恢复线上状态
- 1.服务监控(带宽/QPS/服务资源/存储)降低至正常水平
- 2.如果开发者有报警观察无持续
- 3.如果涉及到消息队列确认无消费积压
- 4.针对压测的配置或代码改造进行恢复
限流验证
限流配置
若有摸高，可按照压测目标值配置限流。
未摸高，可按照压测目标的
70%～80%配置限流。有接口在多个场景复用的，限流需要对各场景QPS限流求和。
限流验证
按照
90%、95%、100%、105%、110%限流值的梯度执行压测。考虑到各限流方案会有误差，限流 验证成功需同时满足如下条件：
- •
90%的时候不触发限流- •在
100%附近开始触发限流- •
≥100%后续成功流量也不能偏移100%太多
限流验证情况记录到报告 3.3 压测进度-限流验证 部分。
全场景稳定性
以略低于限流配置的QPS（
90%～95%），同时对所有的场景执行压测10min，确认整个系统的稳定性。通过标准参考：5.1.2 单压测任务通过标准。
记录结论到报告中。若存在优化事项，需要优化后再行验证。
性能优化
性能问题
现象 | 可能问题 |
|
|
|
|
|
|
|
|
限流问题
排查思路 | 可能问题 |
未达到限流QPS被限流（nginx） | 接口是否复用限流缓冲区配置 |
