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

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

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

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

二、thought与tps

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

三、响应时间

C1：用户请求发出前在客户端须要完成的预处理所须要的时间；

 

C2：客户端收到服务器返回的响应后，对数据进行处理并呈现所须要的时间；

从用户的角度来看，响应时间＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；可是从系统的角度来看，响应时间只包括(A1+A2+A3)+(N1+N2+N3+N4)。

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

 

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

 

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

 

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

 

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

、

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

最佳用户数：吞吐量和资源占用率响应增加，可是用户响应时间变化不大

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

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

对于一个系统来讲，咱们应该 确保系统的最大并发用户数要大于系统须要承受的峰值负载。