来源:51Testing软件测试网
前言:之前一直做的软件质量工作,有过一些经验和一些不太一样的思路,尽管与现在从事产品运营不同,但无论是内涵还是联系,都是非常紧密的,无论如何,我都会继续关注产品的质量问题。
上周跟一朋友阐述性能中并发的概念,叽里咕噜一大通,完了兴致勃勃地让她总结一下,她说了一句:感觉你研究的东西太初级,并发这种概念,太简单,没什么好说的。我听了差点没晕倒,估计她也晕了,真是失败。
并发真的这么简单?性能真的如我们所理解的那样?
也许并不像我们想象的那么简单,之所以我们去探究这些基本的概念,是因为在实际的工作中,我们发现,很多问题到后知后觉才发现,根源在于概念没有统一,抑或没有理解,而无论作为研发人员,还是顾问、销售人员,我们除了自己理解,还需要与客户交流沟通,因此,深刻理解并能通俗易懂的表达出来是非常重要的。
由于软件性能的范围比较大,我们将选取几个典型的问题进行探究,相关概念的理解与分析将逐步进行公开。
● 如何考察性能
这个问题相信很多同事都了然于心了,基本都有自己的理解,我们也很少接到不懂性能的反馈,但很多人甚至包括客户,都把响应时间或者并发用户作为衡量性能的惟一依据,支持10000并发?性能好!响应时间1秒?性能好!有些时候我们也会接到客户一些要求,让我们哭笑不得,某次一客户就要求我们的产品支持10000并发,有点汗,哈哈。
实际上性能是一项工程,严格地说,性能是在某一个特定环境下,系统所表现出来的上限事务处理能力。如果我们将这个问题细化,性能取决于具体环境,取决于系统架构,取决于软件与服务器的优化等等,也就是,我们所提供的内部测试报告是具备一定的前提的(在一定的网络或硬件环境下),如果我们的架构是包含了10台机器的集群,而客户方提供的却是2台PC机,这种条件下还要求测试结果保持一致,就有点为难了。
尽管性能有很多范围、指标、概念,比如响应时间、吞吐量、并发用户、软硬件负荷等等,但对普通用户来说,并发用户数与响应时间这两个概念还是非常直观与普通,认可度也非常高,搞清楚这两个概念非常重要。后面我们会逐步阐述其他概念。
● 理解压力
在谈起并发这个概念之前,我们先来说说压力,对系统而言,性能问题归根到底,都会体现为实实在在的压力。因此,我们一般说的“你这个系统的性能极限能到多少?”,其内在含义指的就是“系统所能承受的极限压力是多少”。
那么压力究竟是什么呢?
我突然想起天天坐的地铁,没有比坐地铁这件事情更便于形容性能与压力了,哈哈。话说我每天在立水桥南上地铁,绝对是考验体力耐力心理素质的事情啊(说岔了)。
我们可以把一班地铁列车看成是一个被测的系统,对于这个系统而言,其压力显而易见,就是列车中所有的人,比如北京地铁5号线,每列车的定员人数是1424人,折合每节车厢237人(当然包括站着的),而极限容纳是1820人,折合每车厢303人,这个总承受人数。
其实就是系统(也就是列车)的特大设计承受压力(也就是吞吐量了),当然,北京地铁比较变态,超员现象比较严重,我每天占用的面积还不超过10平方厘米(脚踮起来了),实际极限负荷估计超过2000了。对列车而言,超过极限负荷是比较危险的,要么是拉不动(这个估计可能性不大),要么人挤坏(君不见每天争吵哀嚎无数)。
如果超出设计负荷值,系统就会存在危险,危险是多方面的,因此,一般的,系统应该具备超出负荷的处理预案,对照到地铁,高峰时期就会进行限流。
搞清楚这个问题后,再来看看常规的系统,就好理解了,系统的压力是什么呢?压力是对被测系统而言的,只要系统在处理事务,就有压力,这种压力不仅仅体现在网络上(数据的吞吐),还体现在服务器上(如CPU、内存等),因此,我们不要混淆了吞吐量与压力的关系,应该这么说,在一些web系统上,吞吐量可以在一定程度上反映系统承受的数据压力。
另外,我们需要清楚,压力不等于性能,压力只是检验性能的一种手段,对一个性能良好的系统,在一定的压力下,应该可以保持正常运转,如果超过负荷,则应该分流或化解压力,这也是我们需要检验的。
● 理解并发
说完压力,我们已经知道,压力其实就是一种作用力,当然,还可以理解为一种量的度量,比如列车的承载数,既然有量,就肯定有速度,承载总量(吞吐量)是一定的,但速度却是变化的,我们早晚高峰的时候去乘地铁,当然是拥挤非常,但如果你晚上11点去做地铁,我可以很高兴地告诉你,你还会有座位!
原因在于,早晚高峰时坐地铁的人多,深夜时坐地铁的人少(这不是废话吗)。我们再来想想,高峰的时候可能同一时间挤进门的人很多,基本上门有多大,同时挤进去的人就能把门给塞满。
那么这个并发(虚拟用户)是什么呢?
并发是有场景条件的,要看我们考察的是什么事情,我们再来想象一下地铁,在整个地铁大厅里(包括列车),有刚刚进站的,有正在买票的,有正在登车的,有坐在车上的,还有闲逛的,这么多人,但对列车有压力的,其实就是已经在车上的这些人(包括挤车的),如果我们考察性能的系统就是列车,很显然,重点关心的就只需要看看车上现有的这些人。
再次强调,并发跟考察的具体场景是有关系的,即并发做什么,并发这个词,原始的翻译是concurrent,意为同时发生的,或同时存在的。至于同时做什么,要看我们定义了,同时在地铁大厅里,同时在地铁上,同时在挤地铁,考察的事情不一样,并发的意义就不一样。
对地铁这个系统而言,每个时间都有新来的人,也有走的人,大家做的事情基本都相同,乘地铁。假定某个时刻地铁大厅中有10000人,检票口候车的有100人,刚刚开走的地铁上乘有2000人,那此时对考察的系统(列车)而言,并发就是2000人,而如果考察的是检票处,则并发为100人,同样,如果考察的系统是地铁大厅,那此时的并发就是10000人。这种并发我们一般称之为“广义并发”。
广义并发有点类似与通常我们所说的在线用户,但存在关键的区别,即并发用户针对的是某一件事务,譬如注册、登录、上传、浏览等,而在线用户是一个很泛的概念,一般包括前面所述的所有事务,可以理解为一个事务集合。
在性能的理论中,还有一个概念,simultaneously,翻译为同步的,当前,为方便计算,我们一般把“同步”理解为“同1秒”,也就是说,这个同步的就是单位时间内发生的数量。也即我们通常所说的“狭义并发”。需要注意的是,实际的测试中经常会遇到被测事务响应时间低于这个1秒的单位时间,此时的并发计算仍需要按1秒计算,具体参见“我们的定义”中的说明。
很多时候,我们(特别是客户)往往搞混了这两个并发的概念。对系统来说,广义的并发实际上是在一个时间内操作事务的虚拟用户,而狭义的并发指的是单位时间内向系统发起请求的虚拟用户,前者是“存在”,后者是“请求”,勿容置疑,压力不仅仅受成功发出请求的用户带来的压力,同时也受“存在”的用户影响。
换种理解方式,并发考察的是系统的处理能力,上限能支持多少用户同时处理某件事务,而不是压力发出端发出的请求。
除此之外,并发作为一个量化的指标,是对应着具体的取值的,因此,很多系统会去寻求特大并发,实际上,我们来回顾5号线的承载力的例子,核定载客1424人,这种情况可能考虑到乘客的感受(还算舒服,站着也算,哈哈)
● 理解我们的定义
在我们已经做过的很多测试中,都有并发这个概念,当然也包括我们很多开发人员,所谓的并发是怎么定义的呢?
客观的说,我们的定义比较接近于“广义并发”,但有所不同。这与我们的考察对象(web系统)、衡量事务(通常我们衡量的都是单个事务,很少把多个事务放在一起处理,原因在于尽量避免事务的耦合性所带来的影响)有关,具体到地铁的例子,如果我们考察的系统指“地铁大厅”,那么我们所谓的并发一般通常指同时进入地铁大厅的人。而如果我们考察的系统指“地铁列车”,那么我们所谓的并发则指同时进入站台的人。
在实际的产品测试中,比如我们在测试IDS登录的时候,如果说,支持800并发,其涵义为“支持800个虚拟用户同时进行登录操作”,需要说明的是,这个同时并非指同一秒,要知道,并发本身是没有单位的。在800并发下的结果如何,要看响应时间,这个问题本文不进行仔细阐述。如有兴趣可以参考相关资料。
测试中,我们也会考虑“狭义并发”的情况,但狭义并发需要考虑到被测系统的入口,比如,假定地铁总共有10个入口且全部开放,每个入口只能容纳1个人进出,则“狭义并发”下特大值就是10?不一定!因为我们还没有考虑速度问题,前面提到,狭义并发的单位是秒,如果每个人经过每个入口的耗时就是1s,则特大“狭义并发”值就是10,如果经过的时间少于1秒呢?还是按1秒算,比如还是这个情景,乘客经过入口的耗时假定为0.1秒,则特大狭义并发就是10/0.1=100了。
简单点说,我们可以这么理解实际工作中的并发,被测的事务总得有人(其实就是虚拟的用户)来做,对吧,同时允许多少用户来做这件事情呢?这个多少用户就是我们需要的并发值。
详询:王萍老师18988787201
详询:小文老师18988787201
王萍老师 | 小文老师 |
《中华考试网软件测试培训》
《教育软件测试培训频道》
《软件测试培训课程——深圳川石》
《深圳川石软件性能测试培训》
《深圳川石企业性能测试(PL&LR)提升班》
《持续集成自动化测试UFT Selenium提升班》
《深圳源昊宝安软件测试培训班》
《深圳凌岳软件自动化测试培训班》
《深圳博睿软件安全测试培训》
《深圳达内软件测试培训学校》