性能测试过程中，因为压力发起环境（简单来说，就是压力机，但不完全等价。如：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平均利用率相差悬殊，这种情况下，恭喜你，最近的辛苦没白费。