图床失效的话，请关注二维码查阅哦😯
扫一扫，关注我

性能测试目的

简单来说：在复杂多变情况下，保证系统稳定

百度百科说：

1. 评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
2. 识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
3. 系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。 检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
4. 验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

性能测试方案关键点

1. 业务系统分析：根据业务和系统运维实际情况，分析 TPS 的时间分布图、HPS/PV 的时间分布图 ELK 获取 TPS 时间分布

1. 场景设计：根据实际的数据容量，业务类型比例，业务时段，业务量来综合设计性能测试场景。举例来说，某 APP 在 12 点-14 点是交易峰值，占用全天交易的 80%，那可以抽取这个时间段内的业务类型比例，产生的比例是，登录:加入购物车:交易:查询订单=10:3:1:6，那在做性能测试场景设计的时候可以采用这一比例进行测试。
2. 监控模型建立：

服务器监控

数据库监控

Docker 监控

JVM 监控 Grafana

JVM 监控 VisualVM

1. 性能问题分析和调优：

数据库问题分析

堆内存泄漏排查

死锁问题排查

JVM 分析

Arthas 调优工具

性能测试通过标准

超时概率：小于0.5‰
错误概率：小于0.5‰
TPS：大于期望高峰值
CPU利用率：小于75%
响应时间：小于期望时间
Load负载：平均没核CPU的Load小于1
JVM内存使用率：小于80%
FullGC频率：平均大于半小时1次

性能测试结果图识别

TPS 和响应时间曲线抖动不能过于强烈，具备一定梯度，整体趋势应该是趋近与平稳

如下图在线程数增加的时候，TPS 一个比较正常的图示，持续增加后，在 13000TPS 的位置趋近平稳，有一定梯度


如下 TPS 和响应时间的图例，可以用作正常类参考



如下图在线程数增加的时候，响应时间在 1s 一下缓慢增涨，当 TPS 到达高点 13000 以后，随时线程持续增加，响应时间增速加剧

不太合理的 TPS 图

波动幅度剧烈，找不到 TPS 的稳定峰值，不利于问题分析，性能测试结果不准确

梯度不明显，可以考虑增加 Ramp-up，让 TPS 增幅变缓，否则响应时间的图也不会出现稳定期，较难做出峰值判断

TPS 在某些点有突然下降，需要做出排查

扫一扫，关注我