以下内容为360QA服务端性能专项团队结合项目实践，对团队中当前应用的六款服务端压力测试工具Loadrunner、Jmeter、SpirentAvalanche、Siege、Tsung、Locust进行分析对比。
● 六款工具特点对比
● 实际案例选型分析
【场景1】
业务接口使用标准HTTP交互json类型数据，该接口承载多用户并发交互请求，测试预期为100并发用户，500TPS的业务处理能力，每用户测试脚本事务逻辑：
http get url_init，获取到sid;
httppost(username.password,sid) url_login,通过认证后获取到token；
http post(token,search_args) url_search,得到list类型的[item1,item2…..itemN];
http post(token, [item1,item2…..itemN])url_get_item_result，得到每个item后台查询后的结果数据，每个item的返回有3种状态，ok+data/error/wait
根据上一个请求的结果，对所有ok/error状态的item进行统计计数，对wait状态的item需要重新发起post请求结果(post时需重新组装所有wait状态的item到新[……itemN]列表)，直到所有item状态为ok或error。
【选型分析】六款压测工具都可以在单机环境下满足本场景压力需求，工具选型的关键点在业务场景的覆盖上，特分析如下：
-
siege一类工具，只能进行简单的协议交互而不满足测试需求；
-
Tsung，受限于XML格式的脚本语法能力约束，不能实现一些基本的编程逻辑，比如在for循环中通过break跳出循环，根据条件重组列表数据结构等，只能通过脚本中引用erlang语句或编写erlang扩展库的方式来实现，考虑到这样实现对Tsung XML脚本语法体系的未知影响以及erlang语言开发的成本，tsung对于一些交互逻辑较复杂的测试场景还是不推荐选用的；
其他几款工具，loadrunner、jmeter和locust由于分别使用c、java和python作为脚本语言，所以实现这类交互逻辑的脚本编程实现比较容易，可以根据自己熟悉的语言选择工具。
【场景2】
业务接口为EAP-MD5交互及加密方式的radius协议，用于提供nas设备(通常为802.1x交换机或网关设备)做802.1X 用户准入认证，测试需求为模拟nas设备与业务接口做大并发的radius认证交互，得到业务接口处理认证请求处理能力及请求成功率/超时率统计，测试预期为支持100个nas设备(并发用户),2000qps的认证请求处理能力。
【选型分析】满足该需求的首选工具是avalanche，完整支持EAP-MD5类型的RADIUS协议，且单口性能远高于测试需求。由于avalanche为商用硬件平台，成本较高，如果使用纯软件实现，对几款工具进行开发扩展的成本分析如下：
-
loadrunner支持c/c++动态库扩展，可以基于开源的freeradius代码(纯c)编写动态库来扩展loadrunner对eap-md5 RADIUS的支持，需要注意的是freeradius只支持linux gcc编译，所以只能扩展linux版本的LR-LoadGenerate的.so库。
-
jmeter用标准java进行扩展，可以基于开源的Jradius(freeradius的java实现)代码编写类库来扩展jmeter对eap-md5 RADIUS的支持。
-
tsung使用erlang语言来扩展，对于当前需求，erlang没有radius的eap-md5实现，鉴于erlang语言的熟练程度，自己实现的成本太高，所以排除tsung工具。
-
locust使用python语言进行扩展，可以使用pyrad库来实现radius协议，但是pyrad原生没有对eap-md5的支持，需要自己通过eap和md5库来做实现，鉴于python的低成本开发，实现比较容易，但是经过对比测试，python的eap-md5 radius相对c和java版本，性能下降较大，通过locust在单机测试很难达到测试的性能指标，所以排除了locust工具。
综合几款工具的扩展能力及成本，最终确定了loadrunner和jmeter可以满足当前需求，最终选型取决于c/java语言的开发熟练度。
【场景3】
业务接口使用标准HTTP get/post交互，接口交互简单，只需要判断每个请求后服务器应答的http return code是否为200，由于服务端为集群架构，需要的测试压力较大，预期为50万并发用户，150万qps。
【选型分析】对于这种弱交互的测试场景，所有工具都可以满足需求，在测试资源成本角度考虑，loadrunner、jmeter、tsung、locust需要大量的测试机来支撑，而avalanche和siege体现出天生的资源占用低、高性能的优势，由于业务接口交互简单也不存在功能不满足的情况，所以该场景首选avalanche或siege来进行。
使用avalanche可以在单个千兆接口上实现18万qps的能力，对于150万qps的压力需求可以绑定9个口进行。
对于没有avalanche测试资源的情况，可以使用低成本的siege工具，siege可以在单台双路E5 cpu的测试机中实现18万qps的压力，并可以统计服务器响应的http return code数量，对于150万qps的压力需求可以使用9台服务器做测试集群，对比tsung，tsung大概需要25台测试机来实现，对比loadrunner，loadrunner大概需要70台测试机。
这里需要注意的是，siege工具不支持分布式调用，在该场景下需要做一个简单包装来支持分布式，比如可以用python pexpect或shell rsh方式编写脚本来跨机操作多台机器上的siege进程。
【场景4】
NSS Labs安全产品认证的测试方案中，许多安全产品的Performance测试都包含一项”Real-world”的混合流量测试，我们以NGFW这个产品的测试方案为例介绍一下如何选择合适的工具实现，如下图说明：
【选型分析】先看Enterprise的流量细节：
再分析各压力工具实现Enterprise的混合流量，具体如下：
-
商用仪表Avalanche：支持Client/Server模拟多协议交互，混合流量比例可控、报表详细（推荐）
-
Siege：不适用上述的混合流量的多协议（不支持）
-
Loadrunner/Jmeter/Tsung/Locust：需要单独搭建各种协议的server，配置成本高，工具中需要配置多种协议测试脚本，混合流量比例较难控制（困难）
跟据上述结论，我们看一下使用Avalanche如何实现Enterprise的混合流量：
第一步测试拓扑(Avalanche直连Firewall)：
第二步client&server配置具体引用层协议细节，以http_text为例：
①client端，配置http协议action为get
②server端，配置上传112k大小文本文件
③完成所有协议配置后，在Associations引用配置
完成上述配置完后，即可发送流量验证，结果如下
从上图可以看出，独立的协议显示结果，过Firewall后可以独立分析。关于NSS Labs的介绍，详见360百科链接：
http://baike.so.com/doc/9416919-9757014.html
【场景5】
业务接口为java JMS/RMI类型，业务交互逻辑复杂，预期为100并发用户，3000tps。
【选型分析】Java JMS/RMI为java私有的类RPC接口，测试时需要压测工具加载对应的java类库用于关联各接口业务class method，目前只有loadrunner和jmeter支持java，loadrunner通过加载一个jvm来实现java支持，而jmeter为原生java实现。所以，对于java接口测试，只能选择loadrunner/jmeter工具。
综上所述，压测项目的工具选型的考虑因素有：
-
被测端的业务逻辑
-
预期的压力大小
-
工具二次开发能力
-
测试人员对工具语言的熟练度
而具体到上述六款工具总结如下：
-
Avalanche：适合网关类型产品测试(同时模拟协议的C/S两端进行交互)，压力规模要求较高， 需要定制2-7层协议交互细节，多协议测试，测试报告有较高要求的场景，不适合业务交互复杂的场景；
-
Siege：适合http/https类型的接口极限基准测试，较低成本实现大压力规模要求的场景，不适合业务交互复杂及非http/https协议测试场景；
-
Loadrunner：适合大多数测试场景，相关文档及社区资料丰富；
-
Jmeter：适合大多数测试场景，尤其适合java私有接口测试(RMI/JMS)；
-
Tsung：适合较低成本实现大压力规模要求的场景，不适合业务交互复杂及需要工具功能扩展的场景；
-
Locust：适合大多数测试场景，尤其适合需要工具功能扩展的场景；不适合较低成本实现大压力规模要求的场景；
正所谓工具善其事，必先利其器，选用适当的工具，可以让我们的工作事半功倍，期望这篇文章能够给您的压力测试工作带来一些帮助，也非常欢迎您的意见和建议，大家一起交流性能测试领域的各种问题。