性能测试-理发店模型[转]

注:绿色标注的是个人理解,建议大家看第一遍的时候忽略,以免误导大家,如果有理解不对的,希望各位前辈指正

相信大家都进过或见过理发店,一间或大或小的铺面,1个或几个理发师,几张理发用的椅子和供顾客等待的长条板凳。

在我们的这个理发店中,我们事先做了如下的假设:

1. 理发店共有3名理发师;(系统资源)

2. 每位理发师剪一个发的时间都是1小时;(处理时间)

3. 我们顾客们都是很有时间观念的人而且非常挑剔,他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时,而且等待时间越长,顾客的满意度越低。如果3个小时还不能剪完头发,我们的顾客会立马生气的走人。(用户可以容忍的系统响应时间为3小时,超过这个时间用户可能会重新请求或者不再请求)

通过上面的假设我们不难想象出下面的场景:

1. 当理发店内只有1位顾客时,只需要有1名理发师为他提供服务,其他两名理发师可能继续等着,也可能会帮忙打打杂。1小时后,这位顾客剪完头发出门走了。那么在这1个小时里,整个理发店只服务了1位顾客,这位顾客花费在这次剪发的时间是1小时;

2. 当理发店内同时有两位顾客时,就会同时有两名理发师在为顾客服务,另外1位发呆或者打杂帮忙。仍然是1小时后,两位顾客剪完头发出门。在这1小时里,理发店服务了两位顾客,这两位顾客花费在剪发的时间均为1小时;

3. 很容易理解,当理发店内同时有三位顾客时,理发店可以在1小时内同时服务三位顾客,每位顾客花费在这次剪发的时间仍然是均为1小时;

从上面几个场景中我们可以发现,在理发店同时服务的顾客数量从1位增加到3位的过程中,随着顾客数量的增多,理发店的整体工作效率在提高,但是每位顾客在理发店内所呆的时间并未延长。(当并发用户数小时最佳并发用户数时,随着用户的增加,响应时间并不会增加,只是系统资源利用率增加了)

当然,我们可以假设当只有1位顾客和2位顾客时,空闲的理发师可以帮忙打杂,使得其他理发师的工作效率提高,并使每位顾客的剪发时间小于1小时。不过即使根据这个假设,虽然随着顾客数量的增多,每位顾客的服务时间有所延长,但是这个时间始终还被控制在顾客可接受的范围之内,并且顾客是不需要等待的。

不过随着理发店的生意越来越好,顾客也越来越多,新的场景出现了。假设有一次顾客A、B、C刚进理发店准备剪发,外面一推门又进来了顾客D、E、F。因为A、B、C三位顾客先到,所以D、E、F三位只好坐在长板凳上等着。1小时后,A、B、C三位剪完头发走了,他们每个人这次剪发所花费的时间均为1小时。可是D、E、F三位就没有这么好运,因为他们要先等A、B、C三位剪完才能剪,所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时和剪发1小时。

通过上面这个场景我们可以发现,对于理发店来说,都是每小时服务三位顾客——第1个小时是A、B、C,第二个小时是D、E、F;但是对于顾客D、E、F来说,“响应时间”延长了。(当并发用户超过最佳并发用户数,随着用户的增加,响应时间会变长)。

在新的场景中,我们假设这次理发店里一次来了9位顾客,根据我们上面的场景,相信你不难推断,这9位顾客中有3位的“响应时间”为1小时,有3位的“响应时间”为2小时(等待1小时+剪发1小时),还有3位的“响应时间”为3小时(等待2小时+剪发1小时)——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10,那么我们已经可以断定,一定会有1位顾客因为“响应时间”过长而无法忍受,最终离开理发店走了。

我想并不需要特别说明,大家也一定可以把上面的这些场景跟性能测试挂上钩了。如果你还是觉得比较抽象,继续看下面的这张图 ^_^

这张图中展示的是1个标准的软件性能模型。在图中有三条曲线,分别表示资源的利用情况(Utilization,包括硬件资源和软件资源)、吞吐量(Throughput,这里是指每秒事务数)以及响应时间(Response Time)。图中坐标轴的横轴从左到右表现了并发用户数(Number of Concurrent Users)的不断增长。(这张图我觉得有问题,对于吞吐量,文中指出说的是每秒处理事务数,如果是指这个的话,理发师每小时剪发的个数是一定的,不管是并发3个还是并发6个、9个,吞吐量不应该呈现上升的趋势啊,随着时间的增加,理发师疲劳了,每小时可能剪不了一个头发了,这时吞吐量下降,所以我觉得文中的图关于吞吐量是错误的。不知道是不是自己理解有误)

在这张图中我们可以看到,最开始,随着并发用户数的增长,资源占用率和吞吐量会相应的增长,但是响应时间的变化不大;不过当并发用户数增长到一定程度后,资源占用达到饱和,吞吐量增长明显放缓甚至停止增长,而响应时间却进一步延长。如果并发用户数继续增长,你会发现软硬件资源占用继续维持在饱和状态,但是吞吐量开始下降,响应时间明显的超出了用户可接受的范围,并且最终导致用户放弃了这次请求甚至离开。

根据这种性能表现,图中划分了三个区域,分别是Light Load(较轻的压力)、Heavy Load(较重的压力)和Buckle Zone(用户无法忍受并放弃请求)。在Light Load和Heavy Load 两个区域交界处的并发用户数,我们称为“最佳并发用户数(The Optimum Number of Concurrent Users)”,而Heavy Load和Buckle Zone两个区域交界处的并发用户数则称为“最大并发用户数(The Maximum Number of Concurrent Users)”。

当系统的负载等于最佳并发用户数时,系统的整体效率最高,没有资源被浪费,用户也不需要等待;当系统负载处于最佳并发用户数和最大并发用户数之间时,系统可以继续工作,但是用户的等待时间延长,满意度开始降低,并且如果负载一直持续,将最终会导致有些用户无法忍受而放弃;而当系统负载大于最大并发用户数时,将注定会导致某些用户无法忍受超长的响应时间而放弃。

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

当然,如果一开始就有10个顾客到来,则注定有1位顾客剪不到头发了。

进一步理解“最佳并发用户数”和“最大并发用户数”

在上一节中,我们详细的描述了并发用户数同资源占用情况、吞吐量以及响应时间的关系,并且提到了两个新的概念——“最佳并发用户数(The Optimum Number of Concurrent Users)”和“最大并发用户数(The Maximum Number of Concurrent Users)”。在这一节中,我们将对“最佳并发用户数”和“最大并发用户数”的定义做更加清晰和明确的说明。

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

要补充的一点是,当我们需要对一个系统长时间施加压力——例如连续加压3-5天,来验证系统的可靠性或者说稳定性时,我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么。(每过一个小时来3个理发的,3个理发师会不停的剪发,而用户不需要等待。理发师处于这种状态很长时间后当然会崩溃)

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

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

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

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

如果你已经理解了上面提到的全部的概念,我想你可以展开进一步的思考,回头看一下自己以往做过的性能测试,看看是否可以对以往的工作产生新的理解。也欢迎大家在这里提出自己的心得或疑惑,继续讨论下去。

理发店模型的进一步扩展

这一节中我会提到一些对理发店模型的扩展,当然,我依然是只讲述现实中的理发店的故事,至于如何将这些扩展同性能测试以及性能解决方案等方面关联起来,就留给大家继续思考了。

扩展场景1:有些顾客已经是理发店的老顾客,他们和理发师已经非常熟悉,理发师可以不用花费太多时间沟通就知道这位顾客的想法。并且理发师对这位顾客的脑袋的形状也很熟悉,所以可以更快的完成一次理发的工作。(类似于相同的账号登陆,如果一直使用一个账号发送请求和参数化不同的用户请求响应时间是不一样的)

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

扩展场景3:随着烫发和染发业务的增加,理发师们决定分工,两位专门剪发,一位专门负责烫发和染发。(分配不同的服务器,不同的服务器提供不同的功能)

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

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

这篇文章就先写到这里了,希望大家在看完之后可以继续思考一下,也写出自己的心得体会或者新的想法,记下自己的不解和疑惑,让我们在不断的交流和讨论中走的更远。

性能测试相关术语的英文书写方法(不断更新ing)——知道了这些术语在英文中的正确书写方法之后,可以通过Google 更加高效的获取到更多有用的资料。

个人理解:

借助这个模型,理解了响应时间、吞吐量、资源占用率、最佳并发用户、最大并发用户。在这个模型中,需要理发的人员(即客户)向理发店(服务器)提出理发的请求,理发师的剪发时间为1小时,即服务器的处理时间,用户的响应时间为进入理发店的门到理发完毕的时间(等待时间+处理时间)。理发店共有3个理发师(系统资源)。

当3个用户并发请求理发时,此时系统资源占用达到饱和,此时资源利用率也是最高的,因为所有的理发时都在忙,没有闲着的。此时的理发人数即最佳并发用户数。

如果再有理发请求,客户需要等待,无法及时响应。当同时到达理发店的人员(并发用户)多于3个,比如9个时,有3个用户响应时间为2小时(1小时等待+1小时理发),还有3个用户响应时间为3小时。即当超过最佳并发用户时,随着用户的增加,系统响应时间变长。

当超过9个用户,同时有10个用户到达理发店理发时,因为第7 8 9用户理完发时,第10个用户已经等待了3个小时,超过的他的极限,所以用户离开了。选择改天再来,或者不来了。即在实际中,用户请求页面,如果页面响应很慢,超过了10s 20s或者更长,用户等待烦了,会选择重新请求或者不再请求。9个用户的时候即为最大并发数,因为超过9个时,就会有超过一个的用户得不到响应。

相关文章

发表评论

返回顶部