包含内容

测试基于真实的负载模型,而不是拍脑袋定一个用户数。

沟通服务内容

负载模型

用户都在做什么、各占多大比例:浏览目录、搜索、下单。

测试脚本

还原真实操作路径的脚本,包括操作之间的停顿。

逐级加压

逐步提高负载,记录从多少并发开始出现性能劣化。

瓶颈定位

最先扛不住的是什么:CPU、内存、磁盘、数据库还是外部服务。

极限测试

超出上限后的表现:是平滑降级还是彻底失效,以及能否自行恢复。

优化建议

该调什么配置、优化什么、扩容什么,以及先后顺序。

工作如何开展

脚本准备需几天;实际跑测很快,且每次优化后都会重跑。

01

明确目标

需要扛住多大负载、响应时间要求是多少。没有具体数字,测试就没有意义。

02

准备

搭建测试环境、编写脚本,并填充与生产量级相当的数据。

03

执行

逐级加压,并在每个档位记录指标。

04

分析

出具报告,列明瓶颈与优化优先级。

在空数据库上做压测毫无意义。一百件商品的目录与十万件的表现完全不同:原本瞬间返回的查询会开始全表扫描。测试环境的数据量必须与生产环境相当。

常见问题

强烈不建议:测试可能把线上打挂,还会污染统计数据。正确做法是在独立环境用副本测试。若确实没有副本,则应在夜间限流并事先协商。

按峰值而不是平均值,并留两三倍余量。平均访问量说明不了什么:流量往往在群发、投放或媒体提及之后突然涌入。

通常的顺序是:先做缓存与数据库查询优化,成本最低且常有成倍效果;其次是扩容资源;重构架构放在最后。

我们来做压力测试

请说明预计的负载与时间点。我们会模拟并指出系统从哪里开始扛不住。