专栏文章 性能测试连载 (18)-分析性能报告时的几个误区

飞天小子的性能课堂 · 2019年11月04日 · 最后由 飞天小子的性能课堂 回复于 2024年02月22日 · 4393 次阅读

性能答疑 QQ 群:777139651

概述

我们用 jmeter 做性能测试,必须需要学会分析测试报告。但是初学者常常因为对概念的不清晰而被测试报告带到沟里去。

常见误区

分析响应时间全用平均值

响应时间不和吞吐量挂钩

响应时间和吞吐量不和成功率挂钩

。。。。。

平均值特别不靠谱

平均值为什么不靠谱?相信大家读新闻的时候经常可以看到,平均工资,平均房价,平均支出,等等字眼,你就知道为什么平均值不靠谱了。

(这些都是数学游戏)

我们做性能测试时,得到的结果数据不会总是一样的,而是波动的。

如果算平均值就会出现这样的情况:测试了 10 次,有 9 次是 1ms,而有 1 次是 10s,那么平均数据就是 1s。

很明显,这完全不能反应性能测试的实际情况,因为那个 10s 的请求就是一个不正常的值。

另外,中位数(Median)可能会比平均数要稍微靠谱一些,中位数的意就是把将一组数据按大小顺序排列,处在最中间位置的一个数叫做这组数据的中位数 ,这意味着有 50% 的数据低于或高于这个中位数。

最为正确的统计做法是用百分比分布统计。TP50 的意思是 50% 的响应时间都小于某个值,TP90 表示 90% 的响应时间小于某个值

我们有一组数据:[ 10ms, 1s, 200ms, 100ms],我们把其从小到大排个序:[10ms, 100ms, 200ms, 1s]。

于是我们知道,TP50 就是 50% 的请求 ceil(4*0.5)=2 时间,是小于 100ms 的;TP90 就是 90% 的请求 ceil(4*0.9)=4,时间小于 1s。

于是:TP50 就是 100ms,TP90 就是 1s

通常更严格一点的响应时间要求是这样的:99% 的请求必须小于 XXms

响应时间务必和吞吐量(Thoughput)挂钩

系统的性能如果只看吞吐量,不看响应时间是没有意义的

我的系统 tps 可以达到 10000,但是响应时间已经到了 20 秒钟,这样的系统已经不可用了,吞吐量也是没有意义的。

当负载上升的时候,系统会逐渐变的不稳定,响应时间也会变得越来越慢,波动越来越大,而吞吐率却开始下降,包括 CPU 的使用率情况也会如此。

所以,当系统变得不稳定的时候,吞吐量已经没有意义了。

所以,吞吐量的值必需配合响应时间来看。例如:TP99 小于 100ms 的时候,系统可以承载的最大并发数是 1000。

响应时间吞吐量和成功率要挂钩

应该不难理解,如果请求都是错误的,还做什么性能测试。

比如,我说我的系统并发可以达到 10 万,但是失败率是 50%,那么这 10 万的并发完全就是一个笑话。

性能测试的失败率的容忍是非常低的。对于一些关键系统,成功率必须在 100%

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 3 条回复 时间 点赞

群怎么是双色球。。。。。有新群吗

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册