性能指标术语&理发店模型

2015-11-26 09:13:53

响应时间

响应时间=呈现时间+系统响应时间

呈现时间取决于数据在被客户端收后到呈现出页面所消耗的时间；

系统响应时间指应用系统从请求发出开始到客户端接收到数据所消耗的时间。

通常可以认为：响应时间=系统响应时间

对一个web应用来说，它的页面响应时间=网络传输时间+应用延迟时间=网络传输时间+数据库延迟时间+应用服务器延迟时间。详细的分解更容易定位性能瓶颈所在。

并发用户数

从业务角度，并发用户数=同一时间段内访问系统的用户数量。

从服务器端承受的压力出发，并发用户数=在同一时刻与服务器进行了交互的在线用户数量。

注意“系统用户数”、“同时在线用户人数”、“并发用户数”的区分，并发用户数取决于业务并发用户数和业务场景。

在实际的性能测试过程中，为了方便，直接把业务并发用户数称为并发用户数。

估算并发用户数：

C=n*L/T; C_max=C+3√C

C是平均的并发用户数；n 是 login session 的数量；L 是 login session 的平均长度；T是考察的时间段长度；C_max是并发用户数的峰值_。

吞吐量

吞吐量是指单位时间内系统处理的客户请求的数量

一般来说，以请求数/秒或者页面数/秒来衡量。

吞吐量计算：

F=N_uv*R/T

F表示吞吐量；N_uv表示虚拟用户的数量；R表示每个虚拟用户发出的请求数量；T表示性能测试所用的时间。

性能计数器

性能计数器是描述服务器或操作系统性能的一些数据指标，例如对于windows系统，使用内存数、进程时间等都是常用的计数器。

另一个相关术语是“资源利用率”，指的是系统各种资源的使用状况，例如CPU占用率68%，内存占用率90%。

思考时间

think time，也称为休眠时间，从业务的角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。用户在使用系统时，不大可能持续不断的发出请求。体现在脚本中，就是在操作之间放置一个think的函数，使得脚本在执行两个操作之间等待一段时间。

每个虚拟用户发出的请求数量R和性能测试所用时间T、思考时间T_s满足关系  R=T/T_s。

通过理发店模型来理解最佳并发用户数和最大并发用户数

模型描述如下：

1、理发店共有3名理发师；
2、每位理发师剪一个发的时间都是1小时；
3、理发店设有等待区，当顾客来到理发店发现没有理发师空闲而为他理发时，顾客就在等待区排队等待，每次理发师要为下一个顾客理发时就从等待区队列的最前面喊一个顾客为其理发，等待区可供排队的长度为无穷大；
4、顾客们都是很有时间观念的人而且非常挑剔，他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，顾客就会极度的不满意而无法容忍，甚至可能生气走人。

假设理发店里一次来了9位顾客（按照到来时间的早晚排位，从A到I），根据我们上面的场景，不难推断，这9位顾客中A、B、C的“响应时间”为1小时，D、E、F的“响应时间”为2小时（等待1小时+剪发1小时），G、H、I 的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了。

横轴代表并发用户数（Number of Concurrent Users），即到来的顾客数。

纵轴代表资源的利用情况（Utilization，包括硬件资源和软件资源），即理发店中忙于理发的理发师数量；

代表吞吐量（Throughput，这里是指每秒事务数），即单位时间（1小时）内完成理发的次数；

代表响应时间（Response Time），即顾客等待开始理发的时间与理发所花时间之和。

划分区域：Light Load（较轻的压力）、Heavy Load（较重的压力）和 Buckle Zone（用户无法忍受并放弃请求）

最佳并发用户数（The Optimum Number of Concurrent Users）在Light Load和Heavy Load 两个区域的交界处；

最大并发用户数（The Maximum Number of Concurrent Users）在Heavy Load和Buckle Zone两个区域的交界处。

显然，每小时3个顾客就是这个理发店的最佳并发用户数，每小时9个顾客则是它的最大并发用户数。当每小时都有3个顾客到来时，理发店的整体工作效率最高；而当每小时都有9个顾客到来时，前几个小时来的顾客还可以忍受，但是随着等待的顾客人数越来越多，等待时间越来越长，最终还是会有顾客无法忍受而离开。同时，随着理发店里顾客人数的增多和理发师工作时间的延长，理发师会逐渐产生疲劳，还要多花一些时间来清理环境和维持秩序，这些因素将最终导致理发师的工作效率随着顾客人数的增多和工作的延长而逐渐的下降，到最后可能要1.5小时甚至2个小时才能剪完1个发了。

对于一个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发用户数”和“最大并发用户数”都是客观存在。以“最佳并发用户数”为例，假如一个系统的最佳并发用户数是50，那么一旦并发量超过这个值，系统的吞吐量和响应时间必然会 “此消彼长”；如果系统负载长期大于这个数，必然会导致用户的满意度降低并最终达到一种无法忍受的地步。所以我们应该 保证最佳并发用户数要大于系统的平均负载。

对于最大并发用户数的识别，需要考虑和鉴别一下以下两种情况：

1.当系统的负载达到最大并发用户数后，响应时间超过了用户可以忍受的最大限度——这个限度应该来源于性能需求，例如：在某个级别的负载下，系统的响应时间应该小于5秒。这里容易疏忽的一点是，不要把顾客因为无法忍受而离开时店内的顾客数量作为理发店的“最大并发用户数”，因为这位顾客是在3小时前到达的，也就是说3小时前理发店内的顾客数量才是我们要找的“最大并发用户数”。而且，这位顾客的离开只是一个开始，可能有会更多的顾客随后也因为无法忍受超长的等待时间而离开；

2.在响应时间还没有到达用户可忍受的最大限度前，有可能已经出现了用户请求的失败。以理发店模型为例，如果理发店只能容纳6位顾客，那么当7位顾客同时来到理发店时，虽然我们可以知道所有顾客都能在可容忍的时间内剪完头发，但是因为理发店容量有限，最终只好有一位顾客打道回府，改天再来。

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

理发店模型的进一步扩展

扩展场景1：有些顾客已经是理发店的老顾客，他们和理发师已经非常熟悉，理发师可以不用花费太多时间沟通就知道这位顾客的想法。并且理发师对这位顾客的脑袋的形状也很熟悉，所以可以更快的完成一次理发的工作。缓存、cookie

扩展场景2：理发店并不是只有剪发一种业务，还提供了烫发染发之类的业务，那么当顾客提出新的要求时，理发师服务一位顾客的时间可能会超过标准的1小时。而且这时如果要计算每位顾客的等待时间就变得复杂了很多，有些顾客的排队时间会比原来预计的延长，并最终导致他们因为无法忍受而离开。

扩展场景3：随着烫发和染发业务的增加，理发师们决定分工，两位专门剪发，一位专门负责烫发和染发。想到了设计模式中的职责单一原则

扩展场景4：理发店的生意越来越好，理发师的数量和理发店的门面已经无法满足顾客的要求，于是理发店的老板决定在旁边再开一家店，并招聘一些工作能力更强的理发师。增加服务器，增加CPU

扩展场景5：理发店的生意变得极为火爆了，两家店都无法满足顾客数量增长的需求，并且有些顾客开始反映到理发店的路途太远，到了以后又因为烫发和染发的人太多而等太久。可是理发店的老板也明白烫发和染发的收入要远远高于剪发阿，于是他脑筋一转，决定继续改变策略，在附近的几个大型小区租用小的铺面开设分店，专职剪发业务；再在市区的繁华路段开设旗舰店，专门为烫发、染发的顾客，以及VIP顾客服务。并增设800电话，当顾客想要剪发时，可以拨打这个电话，并由服务人员根据顾客的居住地点，将其指引到距离最近的一家分店去。系统架构，还想到了数据库中添加索引进行优化