每个公司都有自己的基因。做产品起家的，和网络公司不同。对于性能测试，很多的思维还停留在单机时代。于是很多QA就认为，无非就是测试CPU，memory，disk等参数而已。
但是随着后台的service程序逐渐增多，service的性能测试，和之前测试一个产品，已经有了很多的不同。这里，就谈谈这次性能测试的一些经验。
其实之前QA已经做过了一些性能测试。但是有一天我们计划购入机器为产品上线做准备，manager问我如何购买机器。我一看module不少，首先就考虑如何分配这些moudule在不同的机器上，以获得最好的性能。于是我要搞清楚每个module的性能瓶颈，到底是cpu bound，还是IO bound，还是memory bound。
我就建议QA做了这样的测试。测试结果出来了。从结果看来，扫描病毒的模块CPU还是一个瓶颈，毕竟，扫描病毒是一个很耗时的操作。而web service则需要较多的memory。
我后面关心的就是那么多模块协同工作，谁是最慢的环节。因为我们之前的设计还是考虑的拓展性，所以，对于最慢的环节，通过增加进程数目和增加机器可以改善。
结果出来了，QA很快就根据他们的性能，给出了一组最小的机器配置列表。哪些module可以放在一起，每个module至少要起几个进程才不至于出现特别慢的module block整个service的效率。这下就简单了。我们可以把它作为一个service组，以后增加机器，就按照这样的配置成倍的增加。
其实这样的思路，就是现在所谓的SOA运维。别人问你需要多少机器，如何扩容，你给出的不是几台机器，而是以一个最小的service集群组为单位的系统配置。比如说你的service有3个模块，他们的配置可能是
模块 数目 特征
A 1 CPU bound
B 2 IO bound
C 1 memory bound
意味这增加一个A和C，需要两个B配合。
这样，最小的配置就是 1 cpu，2 disk，1 memory，有可能对于到服务器上面，就是
8core cpu
15000 PRM SAS disk *2
32G memory
有了这样的最小单位，下面才是真正的性能测试环节，我们要知道，这个最小的service单位，能够有多大的吞吐量。
于是，尽可以多地喂数据，看看输出的效率。这时，我们关心的已经不是cpu、memory、io这些参数了，因为你的最小配置必须是这样的。你可能会浪费CPU，浪费内存，但是没有办法，因为瓶颈在那里，要增加机器提高整体吞吐量，IO是瓶颈。 我们关心的是，整个最小的service集合到底能有多大的吞吐量。如果我要更大的吞吐量，需要多少个这样的service单位。
这样的性能测试结果，对产品，对运维才是真正有意义的。这就是从整体的角度去考虑一个service产品。而这也为RD后期的开发起了指导意义，哪个模块是重头戏，对整体而言起决定意义。需要重点调优，哪个模块虽然效率很低，但是调优的优先级可以放低。因为他不是关键。
这里的关键，就在于强调整体测试。而且这个整体是建立在之前模块测试后的模块配比的基础上的。强调最小service集合的测试。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
