如何提高性能测试的效率？
性能测试过程中，因为压力发起环境（简单来说，就是压力机，但不完全等价）的问题而导致性能结果不准确、问题误报、无法到达测试目标的情况也不少见，从笔者目前近百个大小项目的经验中，至少 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 平均利用率相差悬殊，这种情况下，恭喜你，最近的辛苦没白费。
页:
[1]
