很多项目中,压力测试都是耍流氓……
这个问题有很多答案,而每个人内心的答案可能都是不同的。比如,老板要我耍流氓……
做外包项目的大概会懂,压测的目的只是为了一份漂亮的“压测报告(交付物)”。但是,很多场景其实需要进行压力测试的。
一个新的技术引入之前,需要做好评估,压测只是其中一个阶段。
如果很勤快,比如某些中间件的版本升级,都需要进行简单的压测,这样可以排除外部依赖的性能瓶颈。
参数的调整很可能带来一些意想不到的问题,比如 JVM 调整了垃圾回收策略、TCP 改为了 UDP 等等,都需要进行回归压测。通常,不会有问题;意外,总发生在不经意间。
每秒查询率,QPS 是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。 单位是request/s
。
一般压测工具都会有这个指标,简单明了,每秒处理的请求数量
。
6796 requests in 10.05s, 783.13KB read Requests/sec: 676.21 Transfer/sec: 77.92KB 复制代码
比如,当前每秒处理676.21
个请求。
响应时间,这个指标比较多,比如,最小响应时间、平均响应时间、最大响应时间等等,详细指标还有P50
、P95
、P99
等等
Latency Distribution 50% 23.03ms 75% 24.01ms 90% 25.38ms 99% 32.33ms 复制代码
比如,50%
的请求在23.03ms
内返回响应。
虚拟用户,系统模拟并发的用户。主要目的是最大程度的模拟用户操作,从而得到较为准确的压测数据,这个参数一般由压测人员制定,梯度递增。
阶段1: 50虚拟用户,压测1小时; 阶段2: 100虚拟用户,压测1小时; 阶段3: 150虚拟用户,压测1小时; 阶段4: 200虚拟用户,压测1小时; 阶段5: 250虚拟用户,压测1小时; 复制代码
一般在为达到最佳负载的情况下,QPS
会随着VU
的数量等比递增。 比如,50VU
下的QPS
是1000
,那么100VU
下的QPS
会接近2000
。
压测期间,还需要关注下服务器的负载、网络 IO 情况,如果是 Java 工程,观察 JVM 也是很有必要的。如果涉及到外围系统,比如 Mysql、Redis 等,那么也要纳入观察范围。
一般,可视化的图表更有利于分析。
通过这个图,可以看出,在负压不大的情况下,这两个图表是有相同的斜坡
的。 而QPS
在 12:18
时突降,观察 JVM 可以知道,是出现了FGC
。
因为是外网压测,我们允许一定区间的网络波动,如上图的作图,观察P90
、P95
两条曲线,大致在我们预测的范围之内。右图的网格也显示出,大部分请求耗时集中在256ms
到521ms
之间,整体上散射保持一致。
不同的压测工具的优缺点是不同的,设置压测出来的指标也会有较大差异。我们在执行压测时,更应该发现压测中出现的各种各样的问题。
比如,我用jmeter
压测 30s 的QPS
是 5000,而用wrk
的QPS
可能只有 1000,这种情况都是有具体原因的。jmeter
在连接数还每达到最大值的时候,就已经开始计算 QPS 了,导致短时间压测的 QPS 偏大,随着压测时间增长,QPS
会降低。
本文使用 mdnice 排版