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