性能测试解惑之并发压力zt
上一篇 / 下一篇 2012-09-20 23:05:15 / 个人分类:性能测试
X L \N.b5RH:I!If:U0
声明:原创文章,转载请注明出处。51Testing软件测试网/{"z6nx-L;i+Z&y$G$_
前言:之前一直做的软件质量工作,有过一些经验和一些不太成熟的思路,尽管与现在从事产品运营不同,但无论是内涵还是联系,都是非常紧密的,无论如何,我都会继续关注产品的质量问题。 51Testing软件测试网2iM%h@D
nI@Y*Ws
)`w5fy1x0
)E-Up)Zic'r0
上周跟一朋友阐述性能中并发的概念,叽里咕噜一大通,完了兴致勃勃地让她总结一下,她说了一句:感觉你研究的东西太初级,并发这种概念,太简单,没什么好说的。我听了差点没晕倒,估计她也晕了,真是失败。51Testing软件测试网KEL3]Y-hzQ3|
51Testing软件测试网&\EFe|Pi
并发真的这么简单?性能真的如我们所理解的那样?
w1JyxwsjO/Af051Testing软件测试网jI+g1Y{Q.S.y
也许并不像我们想象的那么简单,之所以我们去探究这些基本的概念,是因为在实际的工作中,我们发现,很多问题到最后才发现,根源在于概念没有统一,抑或没有理解,而无论作为研发人员,还是顾问、销售人员,我们除了自己理解,还需要与客户交流沟通,因此,深刻理解并能通俗易懂的表达出来是非常重要的。51Testing软件测试网0}X7[O;X`
)I PDiK#{q-aU0
由于软件性能的范围比较大,我们将选取几个典型的问题进行探究,相关概念的理解与分析将逐步进行公开。51Testing软件测试网 ~kd.uf@|1z9\/t
51Testing软件测试网2J cWyd[`8aP
l 如何考察性能51Testing软件测试网 E;da+ep
这个问题相信很多同事都了然于心了,基本都有自己的理解,我们也很少接到不懂性能的反馈,但很多人甚至包括客户,都把响应时间或者并发用户作为衡量性能的惟一依据,支持10000并发?性能好!响应时间1秒?性能好!有些时候我们也会接到客户一些要求,让我们哭笑不得,某次一客户就要求我们的产品支持10000并发,有点汗,哈哈。51Testing软件测试网#}Y3z,s-M:k3e`
51Testing软件测试网y}:X0X(qd!V
实际上性能是一项工程,严格地说,性能是在某一个特定环境下,系统所表现出来的最大事务处理能力。如果我们将这个问题细化,性能取决于具体环境,取决于系统架构,取决于软件与服务器的优化等等,也就是,我们所提供的内部测试报告是具备一定的前提的(在一定的网络或硬件环境下),如果我们的架构是包含了10台机器的集群,而客户方提供的却是2台PC机,这种条件下还要求测试结果保持一致,就有点为难了。51Testing软件测试网d Y]t*S4B
尽管性能有很多范围、指标、概念,比如响应时间、吞吐量、并发用户、软硬件负荷等等,但对普通用户来说,并发用户数与响应时间这两个概念还是最为直观与普通,认可度也最高,搞清楚这两个概念非常重要。后面我们会逐步阐述其他概念。51Testing软件测试网&j:T*o1b^M7bDY
51Testing软件测试网p~ycu+I.sl
l 理解压力51Testing软件测试网g"f+z*?Y@i0oh)~
51Testing软件测试网3[K]}G)] |
在谈起并发这个概念之前,我们先来说说压力,对系统而言,性能问题归根到底,都会体现为实实在在的压力。因此,我们一般说的“你这个系统的性能最高能到多少?”,其内在含义指的就是“系统所能承受的最大压力是多少”。
?}/v^6S z051Testing软件测试网Jv9NK*W:~ [
那么压力究竟是什么呢?
Jrx`/A mk0EDby1g YZ-A0
我突然想起天天坐的地铁,没有比坐地铁这件事情更便于形容性能与压力了,哈哈。话说我每天在立水桥南上地铁,绝对是考验体力耐力心理素质的事情啊(说岔了)。51Testing软件测试网`eDG"|s g2[
rn!rE P'C~ ]0
我们可以把一班地铁列车看成是一个被测的系统,对于这个系统而言,其压力显而易见,就是列车中所有的人,比如北京地铁5号线,每列车的定员人数是1424人,折合每节车厢237人(当然包括站着的),而最多容纳是1820人,折合每车厢303人,这个总承受人数51Testing软件测试网qhZoe7k+mY
51Testing软件测试网){x7cQ aA
如果超出设计负荷值,系统就会存在危险,危险是多方面的,因此,一般的,系统应该具备超出负荷的处理预案,对照到地铁,高峰时期就会进行限流。51Testing软件测试网 QO:Hh)`
51Testing软件测试网Zg,k&A.V{s
搞清楚这个问题后,再来看看常规的系统,就好理解了,系统的压力是什么呢?压力是对被测系统而言的,只要系统在处理事务,就有压力,这种压力不仅仅体现在网络上(数据的吞吐),还体现在服务器上(如CPU、内存等),因此,我们不要混淆了吞吐量与压力的关系,应该这么说,在一些web系统上,吞吐量可以在一定程度上反映系统承受的数据压力。51Testing软件测试网1b"m4Gk6h,do9q
pzSM1N'h }0
另外,我们需要清楚,压力不等于性能,压力只是检验性能的一种手段,对一个性能良好的系统,在一定的压力下,应该可以保持正常运转,如果超过负荷,则应该分流或化解压力,这也是我们需要检验的。51Testing软件测试网'cg0o4H/m&r-?
51Testing软件测试网{/u m| iS
l 理解并发51Testing软件测试网&n)FN5Iw ?
mf%N]Q1r C0
说完压力,我们已经知道,压力其实就是一种作用力,当然,还可以理解为一种量的度量,比如列车的承载数,既然有量,就肯定有速度,承载总量(吞吐量)是一定的,但速度却是变化的,我们早晚高峰的时候去乘地铁,当然是拥挤非常,但如果你晚上11点去做地铁,我可以很高兴地告诉你,你还会有座位!
O4znnzr0X iA4W0`-u}c@/_0
原因在于,早晚高峰时坐地铁的人多,深夜时坐地铁的人少(这不是废话吗)。我们再来想想,高峰的时候可能同一时间挤进门的人很多,基本上门有多大,同时挤进去的人就能把门给塞满。
e/c pP} hN_051Testing软件测试网$yW4B p o [9`K"^@
那么这个并发(虚拟用户)是什么呢?51Testing软件测试网HFLa t U1Gqx"p B {
51Testing软件测试网2m;NXMC8g7R3m:^3M
并发是有场景条件的,要看我们考察的是什么事情,我们再来想象一下地铁,在整个地铁大厅里(包括列车),有刚刚进站的,有正在买票的,有正在登车的,有坐在车上的,还有闲逛的,这么多人,但对列车有压力的,其实就是已经在车上的这些人(包括挤车的),如果我们考察性能的系统就是列车,很显然,重点关心的就只需要看看车上现有的这些人。51Testing软件测试网of3b6Q6A#u&G$\2}
mX/IY` ]0
再次强调,并发跟考察的具体场景是有关系的,即并发做什么,并发这个词,原始的翻译是concurrent,意为同时发生的,或同时存在的。至于同时做什么,要看我们定义了,同时在地铁大厅里,同时在地铁上,同时在挤地铁,考察的事情不一样,并发的意义就不一样。51Testing软件测试网5K`Q3Q:{_$C J
51Testing软件测试网x"mO/qV,q
对地铁这个系统而言,每个时间都有新来的人,也有走的人,大家做的事情基本都相同,乘地铁。假定某个时刻地铁大厅中有10000人,检票口候车的有100人,刚刚开走的地铁上乘有2000人,那此时对考察的系统(列车)而言,并发就是2000人,而如果考察的是检票处,则并发为100人,同样,如果考察的系统是地铁大厅,那此时的并发就是10000人。这种并发我们一般称之为“广义并发”。
#yw\4c'L051Testing软件测试网/y&K JG ?
广义并发有点类似与通常我们所说的在线用户,但存在关键的区别,即并发用户针对的是某一件事务,譬如注册、登录、上传、浏览等,而在线用户是一个很泛的概念,一般包括前面所述的所有事务,可以理解为一个事务集合。
)~va sys8J{051Testing软件测试网w3SYn_
51Testing软件测试网_Sk8X"FRA
51Testing软件测试网y#M ZaN^$L
51Testing软件测试网K9V4ac V!Y
很多时候,我们(特别是客户)往往搞混了这两个并发的概念。对系统来说,广义的并发实际上是在一个时间内操作事务的虚拟用户,而狭义的并发指的是单位时间内向系统发起请求的虚拟用户,前者是“存在”,后者是“请求”,勿容置疑,压力不仅仅受成功发出请求的用户带来的压力,同时也受“存在”的用户影响。51Testing软件测试网$BY9X YU.M`+e
6t0|O"H"r:k0
换种理解方式,并发考察的是系统的处理能力,最多能支持多少用户同时处理某件事务,而不是压力发出端发出的请求。
yRI!oX)~wNtO0`n`I6xzS*T0
除此之外,并发作为一个量化的指标,是对应着具体的取值的,因此,很多系统会去寻求最大并发,实际上,我们来回顾5号线的承载力的例子,核定载客1424人,这种情况可能考虑到乘客的感受(还算舒服,站着也算,哈哈)
u:hI4t:^Vc/N v051Testing软件测试网.ibxv8?Ny
!j.P3{'dB0#A"T"DRX4J}#r0
在我们已经做过的很多测试中,都有并发这个概念,当然也包括我们很多开发人员,所谓的并发是怎么定义的呢?51Testing软件测试网.EE]L:i"k3Vv
51Testing软件测试网Qx0dz:mh7[1m3l0pP
客观的说,我们的定义比较接近于“广义并发”,但有所不同。这与我们的考察对象(web系统)、衡量事务(通常我们衡量的都是单个事务,很少把多个事务放在一起处理,原因在于尽量避免事务的耦合性所带来的影响)有关,具体到地铁的例子,如果我们考察的系统指“地铁大厅”,那么我们所谓的并发一般通常指同时进入地铁大厅的人。而如果我们考察的系统指“地铁列车”,那么我们所谓的并发则指同时进入站台的人。51Testing软件测试网8w/x4r8K.A
]7[)j8AO&q0
在实际的产品测试中,比如我们在测试IDS登录的时候,如果说,支持800并发,其涵义为“支持800个虚拟用户同时进行登录操作”,需要说明的是,这个同时并非指同一秒,要知道,并发本身是没有单位的。在800并发下的结果如何,要看响应时间,这个问题本文不进行仔细阐述。如有兴趣可以参考相关资料。
N HUm!w6xuu)s0(`V5OUD!P#{5Ib5z0
测试中,我们也会考虑“狭义并发”的情况,但狭义并发需要考虑到被测系统的入口,比如,假定地铁总共有10个入口且全部开放,每个入口只能容纳1个人进出,则“狭义并发”下最大值就是10?不一定!因为我们还没有考虑速度问题,前面提到,狭义并发的单位是秒,如果每个人通过每个入口的耗时就是1s,则最大“狭义并发”值就是10,如果通过的时间少于1秒呢?还是按1秒算,比如还是这个情景,乘客通过入口的耗时假定为0.1秒,则最大狭义并发就是10/0.1=100了。
A-i#M$} Zx1V[0
#cS#rZ{1W4N0
简单点说,我们可以这么理解实际工作中的并发,被测的事务总得有人(其实就是虚拟的用户)来做,对吧,同时允许多少用户来做这件事情呢?这个多少用户就是我们需要的并发值。51Testing软件测试网0[]T/Io
51Testing软件测试网4X J8G!z+QJS#|D
r-c7Vo(C` wd!Xq0/ir0~ Os0
那么我们如何来估算这个并发值呢?51Testing软件测试网O5_w\4y8sP$[
QS,AlU"q-du @G7U0
在此我们需要作出说明,一般我们需要的数据应该来自于实际数据(比如系统日志的记录),这样最可靠,只有当系统新启动且无任何数据参考的时候我们才需要进行估算。51Testing软件测试网$kN6m"ntxBk
51Testing软件测试网 zZhL9j2P/e6]
比如我们测试地铁大厅的性能情况,该如何去估算当乘客进入大厅时,地铁大厅的性能呢?下面以笔者经常乘坐的地铁5号线立水桥南站为例进行估算,过程与数据仅供参考。
;T$W'nQq"m!Jr"X+N9z0假定每天从该站乘坐地铁的人数为5万人次,每天的早高峰为7-9点,晚高峰为6-7点,根据8/2原则,80%的乘客(人次)会在高峰期乘坐该站的地铁,则平均每秒到达地铁检票口的人数为(50000×80%)/(3×60×60) = 3.7~=4人,当然这个4人不能作为计算所用的并发值,因为对此时的受压入口检票口来说,4只是每秒到达的压力(即请求)数量,考虑到安检、入口关闭等因素,实际堆积在检票口的人数可能要大于这个数目,假定每个人需要3秒左右才能入站,则实际并发应该为(4人/秒)×3秒=12。当然我们必须指出,这种方法得到的情况并非极端值,因为即使作为早晚高峰,人数的分布也不是平均的(具体情况需要根据实际数据进行分析),但对大部分系统的大部分场景,我们可以用(用户总量/统计时间)×影响因子(一般为3,为经验系数)来进行估算。
!W"u]U*Ka/W+WH07h:i H%c6gA[z{s0
实际上,还有一种估算方法,而这种估算方法为国内众多书籍、文章反复转载,其来源与Eric Man Wong在2004年公布的一篇“论文”《Method for Estimating the Number of Concurrent Users》,其核心公式如下:51Testing软件测试网/h aSfZM {$u(l&n
C=nL/T
[w]Y6\'r5gl*oJ0其中,C代表在线用户,n代表执行事务的用户总数,L代表每用户的平均在线时间,T为待统计的总时间,依旧以地铁入站的情况进行估算,依旧考虑8/2原则,即n为50000*80%人,T为3小时,L即我们在地铁中停留的时间(从进站到上车),假定为5分钟,因此得到的公式为:
du-H*b SOtqZ0C=(50000人×80%×5min)/3×60min = 1111
SYG1q"l F ?7eBtr ^051Testing软件测试网&h3TS!a.A
并发数是1111,比前面一种算法要高的多,这是为什么呢?51Testing软件测试网V'S8` P"K-R
51Testing软件测试网`+W d4YX}N
实际上,后面这种统计方法是由一定的局限性与适用范围的,对其统计的每个并发用户而言,每个用户所在线的时间(如上面的5min),并不一定是我们所需要的场景耗时,该5分钟应该是整个大场景(如从进站到离开),而我们通常所使用的场景往往包含了一连贯的子场景,如进站、等待、上车等,因此,如果我们测试的场景是某一个具体的动作,不建议采用这种公式(当然,如果单独为每个动作估算时间也是可以的。)
7bt2e_q.S Y051Testing软件测试网w9o~$dJ
从本质上来说,两种公式的统计,结果都是一样的,关键取决与统计口径。
;?5t9jW,sG7n!XC051Testing软件测试网7K$j Bc2F] g
极限的问题也是我们需要考虑的,数据的估算往往是一个大的工程,涉及到很多复杂的情况,比如用户的进入与离开,人流异常等,因此我们考虑的多为常规的情况,在一些特殊的情况下,用户的峰值往往要大很多,此时需要去对极限情况下进行估算。
l*d1Yh^OC0u3yyK al@0
此时的目的在于检查系统的极限承载情况,如列车最大承载2000人,站内极限承载10000人是一样的,超出这个极限,就需要采取一些紧急措施,比如限流(对应到普通的系统,就是设置最大连接数,超出的必须等待)之类。51Testing软件测试网*RJSY$D9?
51Testing软件测试网`"NZ ~ q'vXFt
这种值的计算,不可能给出准确值,可以根据实际情况,协商而定,比如把经验系数更改为5,这种情况下,如果有日志或者统计数据予以支撑,会更加精确。
^2c3WPL!S0