性能压力机环境埋掉的那些坑 - 51ste.com
登录|注册

性能压力机环境埋掉的那些坑

作者:testbird  发布时间:2019-01-08 14:18:17  关键字:高效的性能测试 压力机环境检查 

性能测试过程中,因为压力发起环境(简单来说,就是压力机,但不完全等价。如:Load Generator)的问题而导致性能结果不准确、问题误报、无法到达测试目标的情况也不少见,从笔者目前近百个大小项目的经验中,至少10%的问题出在了压力发起环境。今天来介绍一下这里有什么坑。

性能压力机环境 - 模拟机器人

资源

资源

1、资源配置
大多数人是似乎并不关心压力机的资源情况,往往最多只看看CPU个数、内存大小。
然而还有一些重要的影响因素,它们经常阻碍了测试的进度,这里就一个一个扒一扒。

CPU型号

有一次,团队成员问我,在那个机器上我们发每秒300笔,这个机器就发不到了,CPU个数是一样的呀。这时,看看CPU型号,很可能是不一样的。

虚拟化环境

虚拟化环境中由于资源的争用,导致了发起压力的不稳定。有时候这个虚机能发300笔每秒,有时候只能发200笔每秒,这种抖动的情况,对于性能测试非常不利,根本找不到稳定的TPS去计算各项性能指标。
这时,就去调整虚拟机的设置(如果没有权限的话,找系统管理员),将CPU设置reserved Hz使之相当于物理核的能力,内存设置为reserved,使之获得100%申请的内存。网络的话就要看用到的是什么虚拟机技术了,有些虚拟机技术由于其技术的局限性,IO会反应迟钝一些,只能自求多福了。从实践来看,VMware是性能较优的平台,一分钱一分货。

2、资源利用率

测试环境压力机在执行测试过程中,需关注资源利用情况。这里有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平均利用率相差悬殊,这种情况下,恭喜你,最近的辛苦没白费。

本文由51ste.com网友编辑,未经授权,不得转载使用上述作品盈利;个人转载,需标明原文作者及出处。

更多相关文章

说说看法查看全部评论(0)

ad banner 250
微信二维码

部落微信公众号

QQ二维码

部落QQ群二维码