性能测试过程中,因为压力发起环境(简单来说,就是压力机,但不完全等价)的问题而导致性能结果不准确、问题误报、无法到达测试目标的情况也不少见,从笔者目前近百个大小项目的经验中,至少 10% 的问题出在了压力发起环境。这里介绍一下这里有什么坑。
大多数人是似乎并不关心压力机的资源情况,往往最多只看看 CPU 个数、内存大小。
然而还有一些重要的影响因素,它们经常阻碍了测试的进度,这里就一个一个扒一扒。
CPU 型号
有一次,团队成员问我,在那个机器上我们发每秒 300 笔,这个机器就发不到了, CPU 个数是一样的呀。这时,看看 CPU 型号,很可能是不一样的。
虚拟化环境
虚拟化环境中由于资源的争用,导致了发起压力的不稳定。有时候这个虚机能发 300 笔每秒,有时候只能发 200 笔每秒,这种抖动的情况,对于性能测试非常不利,根本找不到稳定的 TPS 去计算各项性能指标。
这时,就去调整虚拟机的设置(如果没有权限的话,找系统管理员),将 CPU 设置 reserved Hz 使之相当于物理核的能力,内存设置为 reserved ,使之获得 100% 申请的内存。网络的话就要看用到的是什么虚拟机技术了,有些虚拟机技术由于其技术的局限性, IO 会反应迟钝一些,只能自求多福了。从实践来看, VMware 是性能较优的平台,一分钱一分货。
测试环境压力机在执行测试过程中,需关注资源利用情况。这里有 CPU 利用率,内存利用率,磁盘活动时间。
压力机的 CPU 利用率不应超过 70% 。因为系统在 CPU 利用率过高的情况下处理效率不稳定。为了容易理解,举个生活中的例子,如果一个人用 1% 的力气举一个 1 斤的物体,会非常稳,而花 90% 的力气举一个 90 斤的物体,胳膊腿儿就开始抖了,没准下一次就举不起来 90 斤了。 CPU 也是这样,在 CPU 利用率 90% 的情况下,第一次测试达到 500TPS ,第二次测试可能只达到 450TPS 。这种情况下不利于做对比测试,对比测试需要在相同 TPS 下进行对比。
同理,压力机的内存使用率、 IO 能力 不应超过 70% 。
IO 能力
测试过程中,可以顺便看看磁盘 IO ,遇到过好几次压力机的 IO 能力达到了瓶颈,这种情况下可以采用 1 )加压力机 2 )改为更好的存储 3 )调整性能测试软件的逻辑设计,减少 IO 。
Win10 的版本显示的是“活动时间”,之前的版本显示的是 磁盘最长活动时间(相当于 AIX 下面的 diskbusy )
不同的压力发起方式有时会发现性能,设置不合理也会给自己找麻烦。因此,一定要慎重决定如何发起压力。
什么是压力发起方式?
比如说我要每秒发 100 次请求,那么我有 N 种发起方式。
1) 一个进程发送,每隔 10ms 发出去一个请求
2) 100 个进程发送,在头 100ms ,每个进程发一个请求,后面 900ms 大家都休息。
3) 10 个进程发送,大家随机发送,大约每秒钟每个进程发 10 个请求
4) 2 个进程,大家随机发送,大约每秒钟每个进程发 50 个请求
5) 等等
如果后台服务器的处理能力是每 10ms 处理一个请求,那么按照发起方式( 1 )的话,我们的后台服务器端可以平稳的处理掉所有的请求。如果按照发起方式( 2 )的话,就会总出现几十笔请求的堆积。如果按照发起方式( 3 )的话,堆积的数量就比较少。如果按照发起方式( 4 )的话,可能发现怎么也达不到每秒 100 个请求的压力,到处找原因,郁郁寡欢。
遇到过一个案例,测试结果显示,请求的响应时间特别长( 1 秒以上),进而分析,响应时间花在排队的时间非常长,为什么排队呢,就是采用了刚才提到的发起方式( 2 )。而真实的用户场景中,这种情况几乎不存在,这就是由发起方式导致的性能问题误报。
当然,有时候,不同的发起方式会帮助后台系统发现一些逻辑 bug 。比如说,按照不同的发起方式,服务器的 CPU 平均利用率相差悬殊,这种情况下,恭喜你,最近的辛苦没白费。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞2
添加新评论0 条评论