阅读： 2,872
本系列文章对性能测试中容易混淆的概念，方法进行总结。作为性能测试进阶版本，本文假设使用者已经会使用各种仪表，不会对基本配置进行描述。
相关阅读：
【安全测试】性能测试进阶（Part2-新建测试的方法）
【安全测试】性能测试进阶（Part3-并发测试的方法）
基本概念
对下框中HTTP协议的，keep alive等的说明：
建议直接查看思博伦Avalanche的帮助，已经总结得非常完备。不建议查看网上的文档，因为大多数网上的文档并没有彻底搞清楚这几个值的设置，对测试的影响关系，容易越看越晕，不如直接看帮助，一次弄懂。
Conections和simusers的区别和联系
这两个都是测试并发的。Conections和simusers的关系，可以理解为，一个完整的action列表，就是一个simuser。这个actions里面有多少个连接，就对应多少个connections。例如：
假设配置的latency或者think time的时间为60sLatency =60s是服务器会等待60s的时间，再发送200 ok报文Think time=60s 是服务器发送了200 ok后，客户端等待60s再拆掉这个连接
Piggback Get Request是什么意思
设置为piggback get request时，tcp三次握手的第三个报文（即ack报文），可以同时进行数据的传输。
User based 和global profile是什么意思
User based 方式，可以给不同的association配置不同的profile，如下图所示：
而global profile只能使用使用一个profile：
在使用场景上，User based 方式多用于现网模型，可以给不同的流量配置不同的load形状和不同的负载量。
需要特别注意的是，使用User based 方式，测试只能选择simusers或者是simusers/sec，不能选择connection或者connection/sec等而使用global profile可以使用simusers、 simusers/sec， connection和connection/sec等。
Avalanche client端如何判定是否为successful
- 问题1：Monitor里面的结果到底是什么意思，能否直接通过monitor的结果来确定当前的新建还是并发？
答：不可以。Client端的Attempted是累积的tcp的连接值。Server端的Open，per second是实时的。如下图所示：
由于avalanche在建立连接的时候，可以边拆边建，所以attempted的值，并不等同于当前系统正建立的并发。而是系统在测试时间一共建立的多少连接。以上图的例子为例，attempted 802,444个连接，是指client端已经累计发起了802,444个连接。而当前服务器正在建立的连接是516,806（open）个，其中有284,440是已经关闭掉了的连接（closed with rest），当前的新建值为5163（per second）。
- Run-time stats里面，查看对应的TCP新建或者并发（下图中蓝色的线和黄色的线），是否达到期望的结果。如果是http业务，可以同时查看http transitions和response time。
- 还需要保证monitor里面的的unsuccessful结果为0。
- 问题3：Server的closed with error是否是判定结果成功的标准？
Avalanche是4-7层，基于应用的测试。从应用（也就是业务）的角度，可以认为client端成功，client端需要的数据就获取到了，业务传输的目的就达到了。而server端的closed with error是服务器这边的连接出现问题。可以理解为传输层面的问题。所以closed with error可以不作为判定最终结果是否成功的标准，但是是重要的参考项。一般来说，如果在并发中，用think time的方式测试，存在closed with error，用latency的方式，一般客户端就会出现大量失败。
也可以通过avalanche上的result报告来分析当前的问题。对复杂流量来说，通过result报告来分析会特别有帮助。
