每个公司都有自己的基因。做产品起家的,和网络公司不同。对于性能测试,很多的思维还停留在单机时代。于是很多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/