系统性能描述
描述一个系统的性能从来不是一句话或是一个数值的事。在IEEE的定义中:性能是系统或组件在给定约束中实现的指定功能的程度,诸如速度、正确性、内存使用等。
所以性能测试报告中,对系统性能的描述应该是多方面的,如:执行效率、稳定性、兼容行、可靠性、可扩展性容量等;其中,执行效率通过并发用户数、响应时间、吞吐量、成功率、资源消耗综合体现。
并发测试
性能测试有:负载测试、压力测试、配置测试、并发测试、容量测试、稳定性测试。其中,并发测试是测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
在实际的压测中,我们基本上都是设置多个并发,再进行负载测试、压力测试等,因为现实中,我们的系统就是面对多个用户的同时使用,并且,并发用户的数量,直接影响着系统资源的消耗,例如cpu、mem、网络连接、带宽,甚至于系统内部逻辑。
并发怎么看?
所谓并发,它的特点是“并行”和“同时”。
LoadRuner的并发很好理解,就是虚拟用户数。因为LR有个集合点,可以在所有虚拟用户初始化且到达集合点后,再一起执行后续操作,从而达到同时且并行的效果。
但目前在后台性能测试,我们自己开发的工具大多不带集合点功能,这时候使用者对并发的理解就会有点混乱。下面以长连接压测为例:
最简单的一种,一个单进程单线程send工具,启动一次连续发m个包,这种其实属于单并发,请求串是一个接一个串行到达压测对象,一般都要再简单封装下,类似多进程并发:
注意这样还是串行执行,下面这种才能起到并发的作用。
另一种是单进程多线程模式,可以配置起多个线程,一个线程发起一个连接到达压测对象,n个线程就有n个连接,
![](http://f.wetest.qq.com/gqop/10000/20000/LabImage_a6d5b6b8c6e718c307b264524cb5c7f4.jpg)
![](http://f.wetest.qq.com/gqop/10000/20000/LabImage_ec7a3d8fc986b53f3baa3b44f6ec4360.jpg)
以上三种情况,假设所有线程极致同步且系统性能足够,那么同一时间内(或者说同一瞬间),应该是有等同线程个数的请求同时到达系统,并同时被处理完再一起返回,此时线程就是并发,线程数就是并发数,这里理解应该没有问题。
但实际上,所有的并发不可能做到完全同步,压测过程中由于各种影响,比如:各线程初始化速度不一样,连接数不够,处理速度不一样等,导致在并行节奏上相互有了偏差, 这种现象在系统接近性能瓶颈时,会更加突出。所以会有同学疑问,这还能叫“并发”吗? 这里引入“狭义并发”和“广义并发”的概念。
“广义的并发实际上是在一个时间内操作事务的虚拟用户,而狭义的并发指的是单位时间内向系统发起请求的虚拟用户,前者是“存在”,后者是“请求”,勿容置疑,压力不仅仅受成功发出请求的用户带来的压力,同时也受“存在”的用户影响。”
http://www.cnblogs.com/pohome/articles/2073283.html
这样看来,工具中的线程数设置,更偏像是广义并发,代表着在压测时间段内虚拟用户总数,这也是并发原始值。而在后续的压测过程中,在单位时间内,并发数可能会动态变化,这里是狭义并发。
当工具产生的压力远未到系统性能瓶颈时,理论上,狭义并发=广义并发=工具线程数;当压力增加,系统响应时间增长,部分线程的请求处理正常,部分线程可能请求超时,那么同一单位时间内,同时向系统发起请求的用户数就不等于线程数了。
那么我们如何实时掌握压测过程中可能变化的并发?
《Method for Estimating the Number of Concurrent Users》一文介绍了一种并发估算法(网上有很多相关资料,这里不再累述):
C:并发
n:压测时间段内所有的请求数
L:平均响应时间
T:压测总时长
这里注意:L(平均响应时间)≠ T(总时长)/ n(总请求)
压力是什么?
压力就是并发在单位时间内对压测对象的请求数。在我们的压测工具中,有一个配置项专门用来设置压力,可能是所有线程产生的总压力,也可能是单个线程产生的压力。
有些同学会在这里纳闷,为什么我设置了发送10w笔/s的请求,系统吞吐量的计算只有1w笔/s,是不是工具有问题?这里是因为混淆了压力和性能。
“压力不等于性能,压力只是检验性能的一种手段,对一个性能良好的系统,在一定的压力下,应该可以保持正常运转,如果超过负荷,则应该分流或化解压力,这也是我们需要检验的”
http://www.cnblogs.com/pohome/articles/2073283.html
例如:100个并发,1s内发送1w笔请求,如果系统的吞吐量计算大于或等于1w笔/s,说明系统承受住100个并发,1w/s的压力,我们可以增加压力继续测试,直到出现性能拐点;如果系统的吞吐量计算是5k笔/s,则说明,如果我们需要系统应付100个并发,1w/s的压力,解决方案要么提升系统性能一倍,要么扩容一台分流压力。
要特别注意:压力是由工具制造,工具的最大性能决定施加的最大压力。我们在测试过程中曾经遇到压测系统还没到极限,工具已经到瓶颈的情况,这时候得到的压测数据是错误的。
吞吐量如何计算?
我们在压测工具制作中,一直存在一个争议——吞吐量的计算。
在性能测试中,吞吐量的计算有两种常见的公式:
公式1: 吞吐量=并发数/平均响应时间
公式2: 吞吐量=请求总数/总时长
公式1、2大家应该都接触过,虽然看上去不一样,其实理论上都是ok的。首先我们可以从C = nL / T 推导:
并发=请求总数*平均响应时间 / 总时长
=》并发 / 平均响应时间 = 请求总数 / 总时长
=》公式1 = 公式2
然后我们构建三组模型进一步论证:
第一组模型
一共有4个线程,同时发了4笔请求,其中3笔耗时1s,一笔耗时2s,整个过程一共耗时2s。
公式1:
平均响应时间 = (1+1+1+2)/ 4= 1.25s ;
并发 = nL/T =4*1.25/2 =2.5
吞吐量 = 2.5 / 1.25 = 2 笔/s
公式2:
吞吐量 = 总笔数/总耗时 = 4/2= 2 笔/s
第二组模型
一共有4个线程,同时发了4笔请求,4笔请求耗时均为1s,1s内全部发送完毕。
公式1:
平均响应时间 = (1+1+1+1)/ 4= 1s
并发 = nL/T =4*1/1 =4
吞吐量 = 4 / 1= 4 笔/s
公式2:
吞吐量 = 总笔数/总耗时 = 4 / 1= 4 笔/s
第三组模型
一共有4个线程,4笔请求耗时均为1s,但线程发送出现不同步现象,一共持续1.5s完成全部:
公式1:
平均响应时间 = (1+1+1+1)/ 4= 1s
并发 = nL/T =4*1/1.5 =2.67
吞吐量 = 2.67 / 1= 2.67 笔/s
公式2:
吞吐量 = 总笔数/总耗时 = 4 / 1.5 = 2.67 笔/s
从我们构建的模型上看,两个公式计算的结果是相等的。但是,这种平衡是建立在并发稳定的基础上,并发如果变化,结果就会有差异。下面我们看一组真实的压测数据
从上图中看出,实际压测时,两个公式还是会有些微差别,这就是因为我们本来预想并发应该=工具线程数,但在压测过程中,实际并发发生了变化,我们再反推下实际的并发数
计算出的实际并发确实稍低于工具线程数。
结论
1、 在单接口压测时,我们用“请求总数/总时长”得到吞吐量;然后再用“吞吐量*平均响应时间”得到实际并发,此举可用来观察系统实际承受的并发;
2、 在多接口压测时,由于短板效应,同一个流程中的所有接口获得的请求总数和总时长都一样,显然“请求总数/总时长”计算各个子接口的吞吐量不合适,所以改用“并发/平均响应时间”,其中的并发数应在压测工具中埋点统计,不可简单使用工具线程数。
结语
在性能测试平台的开发中,为了测试结果更接近现实,我们在吞吐量计算上改过三个版本,小伙伴们也有过几次激烈的讨论,正是对这种小细节的不断纠缠,我们对性能测试的认识也在不断刷新,原本以为正确的地方被颠覆,不理解的环节逐渐清晰,越琢磨越会发现性能测试的有趣。
如文中观点有理解不到位的地方,欢迎大家一起探讨指正。