Jackei 的测试生活与人文社会读本

带着梦想和激情在现实中旅行
posts - 812, comments - 3861, trackbacks - 26, articles - 0
  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理

版权声明:本文可以被转载,但是在未经本人许可前,不得用于任何商业用途或其他以盈利为目的的用途。本人保留对本文的一切权利。如需转载,请在转载是保留此版权声明,并保证本文的完整性。也请转贴者理解创作的辛劳,尊重作者的劳动成果。

作者:陈雷 (Jackei)

邮箱:jackeichan@gmail.com

Bloghttp://jackei.cnblogs.com

 

大概在一年前的一次讨论中,我的好友陈华第一次提到了这个模型的最初版本,经过几次讨论后,我们发现经过完善和扩展的“理发店模型”可以用来帮助我们理解很多性能测试的概念和理论,以及一些测试中遇到的问题。在最近的一次讨论后,我决定撰写一篇文章来专门讲述一下这个模型,希望可以帮助大家更好的理解性能测试有关的知识。

不过,在这篇文章中,我将会尽量的只描述模型本身以及相关的一些扩展,而具体如何将这个模型完全同性能测试关联起来,我不会全部说破,留下足够的空间让大家继续思考和总结,最好也一起来对这个模型做进一步的完善和扩展^_^ 我相信,当大家在思考的过程中有所收获并有所突破时,那种快感和收获的喜悦才真的是让人倍感振奋而且终生难忘的 ^_^

当然,我要说明的是,这个模型仅仅是1个模型,它与大家实际工作中遇到的各式各样的情况未必都可以一一对应,但是大的方向和趋势应该是一致的。

 

理发店模型

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

理发店模型的进一步扩展

相关资料

 

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

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

 

1.        理发店共有3名理发师;

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

3.      我们顾客们都是很有时间观念的人而且非常挑剔,他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时,而且等待时间越长,顾客的满意度越低。如果3个小时还不能剪完头发,我们的顾客会立马生气的走人。

 

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

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

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

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

从上面几个场景中我们可以发现,在理发店同时服务的顾客数量从1位增加到3位的过程中,随着顾客数量的增多,理发店的整体工作效率在提高,但是每位顾客在理发店内所呆的时间并未延长。

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

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

通过上面这个场景我们可以发现,对于理发店来说,都是每小时服务三位顾客——第1个小时是ABC,第二个小时是DEF;但是对于顾客DEF来说,“响应时间”延长了。如果你可以理解上面的这些场景,就可以继续往下看了。

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

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

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

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

根据这种性能表现,图中划分了三个区域,分别是Light Load(较轻的压力)、Heavy Load(较重的压力)和Buckle Zone(用户无法忍受并放弃请求)。在Light LoadHeavy Load 两个区域交界处的并发用户数,我们称为“最佳并发用户数(The Optimum Number of Concurrent Users”,而Heavy LoadBuckle 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天,来验证系统的可靠性或者说稳定性时,我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么 ^_^

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

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

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

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

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

 

理发店模型的进一步扩展

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

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

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

扩展场景3:随着烫发和染发业务的增加,理发师们决定分工,两位专门剪发,一位专门负责烫发和染发。

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

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

 

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

 

参考资料

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

点击这里了解整个系列的创作进度,查看文章目录,或浏览已经完成的文章。

Feedback

#1楼   回复  引用    

2006-11-20 00:37 by Zee[未注册用户]
第一个顶。

#2楼   回复  引用  查看    

2006-11-20 00:37 by Dflying Chen      
支持一下!

#3楼   回复  引用    

2006-11-20 09:17 by Emily wong[未注册用户]
Mark住先,一阵睇~

#4楼   回复  引用    

2006-11-20 11:44 by sa[未注册用户]
学习

#5楼   回复  引用    

2006-11-20 12:41 by 快乐逍遥[未注册用户]
钢印~

#6楼   回复  引用    

2006-11-20 12:50 by Eric Chu[未注册用户]
对理发店模型我有个疑问,微观上来说,在单CPU的情况下,并不存在真正意义上的并发响应(并发请求是可能的),那么3个理发师同时工作如何解释上述问题?

#7楼   回复  引用    

2006-11-20 12:56 by Eric Chu[未注册用户]
接上。如果微观上系统处理每个请求都需要排队的原理正确的话。假设10个用户并发,系统处理1个用户的请求需要100毫秒,那么处理完这10个的话就需要1秒,那么文中的吞吐量(Throughput,这里是指每秒事务数)就为10;假设20个用户并发,系统处理1个用户的请求仍然需要100毫秒,那么处理完这20个的话就需要2秒,吞吐量(Throughput,这里是指每秒事务数)仍为10,或者会下降(因为处理20个可能时间会长),和文中图的吞吐量上升矛盾, 请问如何解释?

#8楼[楼主]   回复  引用  查看    

2006-11-20 13:18 by Jackei      
@Eric Chu

非常感谢您的回复 ^_^

第一个问题:
说的对。操作系统实际上是分时处理的系统,CPU 时间被以时间片为单位轮流分配给不同的进程——但是操作系统的这种做法本身也是为了让每个进程都感觉到自己在独占 CPU。从这个角度来说,如果我们的理发师可以以极为快速(例如10ms一个间隔)的速度在三位顾客之间切换,而且这个切换是我们根本无法发现或者识别的,我们是否可以认为相当于有三位理发师同时在为顾客服务呢?

第二个问题:
如果10个用户并发时,系统处理1个用户的请求需要100毫秒,当20个用户并发时,系统处理1个用户的请求仍然需要100毫秒,那么这说明10用户并发可能已经是系统的最佳并发量,而进一步增加负载,会进入第二个阶段,也就是“当系统负载处于最佳并发用户数和最大并发用户数之间时,系统可以继续工作,但是用户的等待时间延长,满意度开始降低,并且如果负载一直持续,将最终会导致有些用户无法忍受而放弃”。

不知道上面的回答是否可以解释您的疑问?如果有不同的意见和看法,请不吝赐教 ^_^

#9楼   回复  引用    

2006-11-20 13:56 by LR低手[未注册用户]
请你不要已“LoadRunner 没有告诉你的”这个为题!因为这些LR都告诉你了!
第二、我觉得很失望!一个简单的理论被你简单的说了这么长篇大论!没有什么实用价值!
不过也确实每个人有每个人的见解!只是对你的标题不适合实际!所以提出一些疑义!

#10楼   回复  引用    

2006-11-20 21:32 by 华华[匿名][未注册用户]
同时回答你两个问题
a、这里的并发数是指“并发连接”,是个状态。不是并发请求,也不是并发响应,这两个概念都指是动作
b、并不是任何请求都需要排队的,系统并发数小于最佳并发数时,不需要排队,来了直接剪
————————————————————————
1。对理发店模型我有个疑问,微观上来说,在单CPU的情况下,并不存在真正意义上的并发响应(并发请求是可能的),那么3个理发师同时工作如何解释上述问题?
2。接上。如果微观上系统处理每个请求都需要排队的原理正确的话。假设10个用户并发,系统处理1个用户的请求需要100毫秒,那么处理完这10个的话就需要1秒,那么文中的吞吐量(Throughput,这里是指每秒事务数)就为10;假设20个用户并发,系统处理1个用户的请求仍然需要100毫秒,那么处理完这20个的话就需要2秒,吞吐量(Throughput,这里是指每秒事务数)仍为10,或者会下降(因为处理20个可能时间会长),和文中图的吞吐量上升矛盾, 请问如何解释?

#11楼   回复  引用    

2006-11-25 18:23 by sissy[匿名][未注册用户]
我对此有疑问:“如果10个用户并发时,系统处理1个用户的请求需要100毫秒,当20个用户并发时,系统处理1个用户的请求仍然需要100毫秒,那么这说明10用户并发可能已经是系统的最佳并发量,”
我觉得在这里说10个用户可能就是系统的最佳并发数量可能不正确,20个用户的时候系统的响应时间也没有增长啊,要是20个用户的时候系统的响应时间增长了再得出系统的最佳并发数可能是对的。

#12楼[楼主]   回复  引用  查看    

2006-11-25 19:23 by Jackei      
@sissy[匿名]
您提到的这部分是针对 Eric 朋友的疑问而做出的解答。

其实评价是否最佳并发用户数的标准就像文中提到的:随着并发量的增加,吞吐量(每秒事务数)不再响应的增加,并且响应时间继续增长。

我想如果看上面的那个图会比较清晰一些。

#13楼   回复  引用    

2006-11-25 22:36 by tacy_lee[未注册用户]
是否可以这样描述,理发店里面有些人负责招待客人,店里的座位也是有限的,当超过店里的招待能力时候,有些客户就会被拒绝。

理发师可以同时为3个客人服务,当同时服务超过3个客人的时候,他在客户之间频繁的切换导致工作效率的下降(疲劳的比喻不太合适),并最终导致客户投诉(或者离开)。



#14楼[楼主]   回复  引用  查看    

2006-11-27 21:31 by Jackei      
@tacy_lee
也可以这样理解,不过在实际测试时,很多时候是还没有达到最大的接待能力时,用户已经等待时间过长而无法忍受了。

感谢你的留言,有机会多多交流 ^_^

#15楼   回复  引用    

2006-12-05 09:35 by cx[匿名][未注册用户]
很早就有人讨论文中所描述的论点,不过采用的例子不同,有的用电梯,有的用卖票窗口,但含义是类似的。
作者有兴趣可以去查查。

#16楼   回复  引用    

2006-12-08 13:05 by kuisse[未注册用户]
是比较基础的理论,还是蛮生动的,值得扩展

#17楼   回复  引用    

2006-12-19 15:19 by xingcyx[未注册用户]
文中有两句话,反复看了几遍,还是不大理解,建议LZ再详细展开论述,或者在这里解答:
1、“保证最佳并发用户数要大于系统的平均负载。”
2、“确保系统的最大并发用户数要大于系统需要承受的峰值负载。”

尤其是第2句,好象总觉得很费解。

#18楼[楼主]   回复  引用  查看    

2006-12-19 15:27 by Jackei      
@xingcyx

我的意思是:如果系统的峰值负载是 1000个请求/秒,那么你的系统所能支持的最大并发用户数也应该大于这个数。在这种情况下,系统可以继续为用户提供服务,但是响应时间已经接近用户所能忍受的最大时间。

#19楼   回复  引用    

2006-12-19 15:45 by xingcyx[未注册用户]
系统的峰值负载又是怎么定义的呢?
LZ你的QQ或MSN是多少?
能否在上面深入讨论?

#20楼[楼主]   回复  引用  查看    

2006-12-19 23:23 by Jackei      
@xingcyx

说点个人理解。
1.峰值负载应该是性能需求的一部分,表示系统有可能要面对的最大并发量,是一种极限情况。在这种极限情况下,系统可以继续为用户提供服务,但是响应时间已经接近用户所能忍受的最大时间。另外,因为这是一种极限情况,所以应该认为峰值负载不会长期持续存在,如果峰值负载长期持续存在,必然导致大量用户请求失败。不过当峰值负载逐渐降回到平均负载水平时,系统的响应能力也应当恢复到相应的水平;
2.通常有一种算法,认为峰值负载相当于平均负载的 1.5-2 倍,当然也有人认为可以是 1.5-10 倍;
3.也可以根据客户以往的业务情况来分析客户的业务量以及每年、每月、每周、每天的峰值业务量。如果客户有旧的系统,可以根据已有系统的访问日志,数据库记录,业务报表来分析。要特别注意的是,不同行业、不同应用、不同的业务是有各自的特点的。例如,购物网站在平时的负载主要集中在晚上,但是节假日时访问量和交易量会是平时的数倍;而地铁的售票系统面临的高峰除了周末,还有周一到周五的一早一晚上下班时间。

#21楼   回复  引用    

2006-12-21 22:36 by 墨者[未注册用户]
路过

#22楼   回复  引用    

2007-01-17 10:48 by 陈言[未注册用户]
好文章,深入浅出。

#23楼   回复  引用    

2007-02-11 21:06 by 1982[未注册用户]
当我们面对一个系统的时候又怎么来知道他的最佳并发用户数呢

#24楼[楼主]   回复  引用  查看    

2007-02-13 13:22 by Jackei      
@1982

这就是我们做性能测试的一个重要目的——找出“最佳并发用户数”!

#25楼   回复  引用    

2007-03-05 18:08 by lanyulijy[未注册用户]
好文章,使我一直存在的困惑有了更进一步的了解

#26楼   回复  引用    

2007-03-05 20:46 by 阳光的味道[未注册用户]
写的很好,我可以复制下吗??

#27楼[楼主]   回复  引用  查看    

2007-03-05 22:22 by Jackei      
@阳光的味道

可以,但是如果是转载,请保留文章开头的版权声明,并保证文章的完整性。谢谢 ^_^

#28楼   回复  引用    

2007-03-07 13:35 by ricky[未注册用户]
写的非常好,转载一下.

多谢.

#29楼   回复  引用    

2007-04-01 16:29 by 岁月如哥[未注册用户]
恩 写的太好了 如果这样下去可以在开呀 或者是什么加盟店之累的

#30楼   回复  引用    

2007-04-03 17:25 by jlsv[未注册用户]
看了上面的文章很受启发,另外我有问题想问:

上面的例子中,一个事件的处理中(理发师对一个顾客理发)的系统负载强度是恒定的(看上去作者是这样假设的),而一般来说一个欲测试的功能的请求中系统的负载都是不同的,那么请问,如果现在有一个功能,它整个的运行时间比较长,,并且其中有一个请求非常耗费系统资源。那么在寻找最佳响应用户数的过程中是以整个功能的响应时间来判断呢,还是只需要注意最耗费资源的那个请求?

#31楼   回复  引用    

2007-04-29 11:13 by vivin[未注册用户]
是否可以认为性能稳定的“平均事务响应时间”图,从整体上看,是一条有一定斜率的直线?

#32楼   回复  引用    

2007-05-14 16:21 by Jason S.H.Chen[未注册用户]
非常有意思.有必要继续讨论下去;用通俗易懂的事情来类比.

#33楼   回复  引用    

2007-06-09 13:37 by 121212[未注册用户]
写的不错
www.movebook.cn

#34楼   回复  引用    

2007-06-19 22:45 by testxxh[未注册用户]
我想问一下,最佳并发用户数与并发度是什么关系呢?我看有些文章上写并发度,不清楚这个值是如何计算出来的

#35楼[楼主]   回复  引用  查看    

2007-06-19 23:26 by Jackei      
@testxxh
不好意思,没有接触过“并发度”这个概念。您是在哪些文章中看到的?

#36楼[楼主]   回复  引用  查看    

2007-06-19 23:32 by Jackei      
@jlsv

没有理解您提到的“一般来说一个欲测试的功能的请求中系统的负载都是不同的”是指的什么意思。

另外,如果如你所言,“有一个请求非常耗费系统资源”,那么这个请求本身就很容易成为整个交易中的“瓶颈”,就像木桶上的“短板”。建议先解决这个请求的性能问题。

@vivin

是否可以认为性能稳定的“平均事务响应时间”图,从整体上看,是一条有一定斜率的直线?
——可以认为是这样的。

#37楼   回复  引用    

2007-08-08 15:11 by fenfen[未注册用户]
吞吐量(Throughput,这里是指每秒事务数)?那transactions per Second又是什么?

#38楼[楼主]   回复  引用  查看    

2007-08-09 20:00 by Jackei      
@fenfen

transactions per Second : 每秒完成的交易数。

#39楼   回复  引用    

2007-09-04 16:17 by fei[未注册用户]
我对吞吐量的概念一直不是很明白,可否解释一下。
还有吞吐量与transactions per Second 有关系吗?

#40楼   回复  引用    

2007-10-10 11:17 by david2878[未注册用户]
文章蛮好,谢了。

#41楼[楼主]   回复  引用  查看    

2007-11-15 02:21 by Jackei      
@fei
在很多性能测试的文章中,会把“吞吐量(Throughput)”和“Transaction per Second”作为相同的概念。但是在 LR 中,Throughput 这个 Counter 是指的网络吞吐量。

#42楼   回复  引用    

2007-12-11 20:43 by okokokk[未注册用户]
看过后,回头想一下自己以往做过的性能测试,很有启发。喜欢你的博客。

#43楼[楼主]   回复  引用  查看    

2007-12-12 07:40 by Jackei      
@okokokk
呵呵,多谢支持 :)

#44楼   回复  引用    

2007-12-27 17:08 by haixiao[未注册用户]
楼主说的不错,我可不可以这样理解:一个CPU相当于一个理发师,一个服务器又有几个CPU,当业务扩展的时候,需要增加CPU,再增长的时候需要增加服务器;业务达到一定的水准的时候分成专门的服务器提供具体的服务;电话相当于一个域名解析服务器,根据不同的提交服务转到不同的服务器。
针对不同的用户的性能需求可以将功能分解起来测试。
我是个初学者,在这里发表些自己想法!见笑啦!

#45楼   回复  引用    

2008-04-21 22:42 by Wins[未注册用户]
我一直都有个“取款机”模型,呵呵

#46楼   回复  引用    

2008-07-10 17:51 by 丁[未注册用户]
在这里受教了,谢谢LZ

#47楼   回复  引用    

2008-07-14 17:41 by FLJS[未注册用户]
看了Jackei BLOG的这篇,很受启发,谢谢!!! 希望能继续提供好的技术资料!

#48楼   回复  引用    

2008-08-06 14:25 by 12[未注册用户]
顶。。

#49楼   回复  引用    

2008-12-07 11:55 by xn_selena[未注册用户]
我想请问如何在压力测试过程中根据各指标精确找到性能测试中的最佳并发用户数和最大并发用户数,有没有计算公式?

#50楼   回复  引用  查看    

2009-03-26 14:38 by Testing of S小调      
很形象,收藏了。
对于新手理解性能测试一些基本概念有很大帮助。



发表评论

昵称: [登录] [注册]

主页:

邮箱:(仅博主可见)

评论内容:

  登录  注册

[使用Ctrl+Enter键快速提交评论]

0 565527




相关文章:

相关链接: