码迷,mamicode.com
首页 > 其他好文 > 详细

性能测试中容易混淆的概念

时间:2016-09-05 14:00:01      阅读:143      评论:0      收藏:0      [点我收藏+]

标签:

1、并发用户数≠每秒请求数

      简单说,当你在性能测试工具或者脚本中设置了100并发用户数后,并不能期望着一定会有每秒100个请求发给服务器。事实上,对于一个虚拟用户来说,每秒发出多少请求只跟服务器返回响应的速度有关,如果虚拟用户在0.5秒内就收到了响应,那么它会立即发出第二个请求;而如果要一直等待3秒才能得到响应,它将会一直等到收到响应后才发出第二个请求。例如,如果用户发出请求后,0.2s内得到响应,那么100个用户每秒完成500个请求;只有当响应时间恰好是1秒时,并发用户数才会等于每秒请求数.

     也就是说,并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理,而并不一定是保证每秒中发送100个请求给服务器。

2、thought与tps

     在不同的测试工具中,对于吞吐量(Throughput)会有不同的解释。例如,在LoadRunner中,这个指标是以字节数为单位来衡量网络吞吐量的,而在JMeter中则是以事务数/秒为单位来衡量系统的响应能力的。不过在大多数英文的性能测试方面的书籍或资料中,吞吐量的定义使用的是后者。

3、响应时间

技术分享

C1:用户请求发出前在客户端需要完成的预处理所需要的时间;

 

C2:客户端收到服务器返回的响应后,对数据进行处理并呈现所需要的时间;

从用户的角度来看,响应时间=(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4);但是从系统的角度来看,响应时间只包括(A1+A2+A3)+(N1+N2+N3+N4)。

4、如何评价性能的优劣:用户视角vs.系统视角

 

对于最终用户(End-User)来说,评价系统的性能好坏只有一个字——“快”。最终用户并不需要关心系统当前的状态——即使系统这时正在处理着成千上万的请求,对于用户来说,由他所发出的这个请求是他唯一需要关心的,系统对用户请求的响应速度决定了用户对系统性能的评价。

 

而对于系统的运营商和开发商来说,期望的是能够让尽可能多的用户在任意时刻都拥有最好的体验,这就要确保系统能够在同一时间内处理更多的用户请求。正如在《理发店模型》一文中所描述的:系统的负载(并发用户数)与吞吐量(每秒事务数)、响应时间以及资源利用率(包括软硬件资源)之间存在着一个“此消彼长”的关系。因此,从系统的运营商和开发商的角度来看,所谓的“性能”是一个整体的概念,是系统的负载与吞吐量、可接受的响应时间以及资源利用率之间的平衡。

 

换句话说,“好的性能”意味着更大的最佳并发用户数(The Optimum Number of Concurrent Users)和最大并发用户数(The Maximum Number of Concurrent Users)。

 

5、最佳用户数与最大用户数

技术分享

    图中有三条曲线,分别表示资源的利用情况Utilization,包括硬件资源和软件资源)、吞吐量Throughput,这里是指每秒事务数)以及响应时间Response Time)。图中坐标轴的横轴从左到右表现了并发用户数Number of Concurrent Users)的不断增长。

最佳用户数:吞吐量和资源占用率响应增长,但是用户响应时间变化不大

最大用户数:资源占用达到饱和,吞吐量增长明显放缓甚至停止增长,而响应时间却进一步延长

举例,假如一个系统的最佳并发用户数是50,那么一旦并发量超过这个值,系统的吞吐量和响应时间必然会 “此消彼长”;如果系统负载长期大于这个数,必然会导致用户的满意度降低并最终达到一种无法忍受的地步。所以我们应该 保证最佳并发用户数要大于系统的平均负载。要补充的一点是,当我们需要对一个系统长时间施加压力——例如连续加压3-5天,来验证系统的可靠性或者说稳定性时,我们所使用的并发用户数应该等于或小于“最佳并发用户数”

对于一个系统来说,我们应该 确保系统的最大并发用户数要大于系统需要承受的峰值负载

 

性能测试中容易混淆的概念

标签:

原文地址:http://www.cnblogs.com/zyp1/p/5841807.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!