性能测试解惑之并发压力（一）

来源：教育联展网｜发布时间：｜编辑：佚名

来源：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