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

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

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

来源：51Testing软件测试网

● 如何估算并发
那么我们如何来估算这个并发值呢？
在此我们需要作出说明，一般我们需要的数据应该来自于实际数据（比如系统日志的记录），这样更可靠，只有当系统新启动且无任何数据参考的时候我们才需要进行估算。
比如我们测试地铁大厅的性能情况，该如何去估算当乘客进入大厅时，地铁大厅的性能呢？下面以笔者经常乘坐的地铁5号线立水桥南站为例进行估算，过程与数据仅供参考。
假定每天从该站乘坐地铁的人数为5万人次，每天的早高峰为7-9点，晚高峰为6-7点，根据8/2原则，80%的乘客（人次）会在高峰期乘坐该站的地铁，则平均每秒到达地铁检票口的人数为（50000×80%）/（3×60×60） = 3.7～=4人，当然这个4人不能作为计算所用的并发值，因为对此时的受压入口检票口来说，4只是每秒到达的压力（即请求）数量，考虑到安检、入口关闭等因素，实际堆积在检票口的人数可能要大于这个数目，假定每个人需要3秒左右才能入站，则实际并发应该为（4人/秒）×3秒=12。当然我们必须指出，这种方法得到的情况并非极端值，因为即使作为早晚高峰，人数的分布也不是平均的（具体情况需要根据实际数据进行分析），但对大部分系统的大部分场景，我们可以用（用户总量/统计时间）×影响因子（一般为3，为经验系数）来进行估算。
实际上，还有一种估算方法，而这种估算方法为国内众多书籍、文章反复转载，其来源与Eric Man Wong在2004年公布的一篇“论文”《Method for Estimating the Number of Concurrent Users》，其核心公式如下：
C=nL/T
其中，C代表在线用户，n代表执行事务的用户总数，L代表每用户的平均在线时间，T为待统计的总时间，依旧以地铁入站的情况进行估算，依旧考虑8/2原则，即n为50000*80%人，T为3小时，L即我们在地铁中停留的时间（从进站到上车），假定为5分钟，因此得到的公式为：
C=（50000人×80%×5min）/3×60min = 1111
并发数是1111，比前面一种算法要高的多，这是为什么呢？
实际上，后面这种统计方法是由一定的局限性与适用范围的，对其统计的每个并发用户而言，每个用户所在线的时间（如上面的5min），并不一定是我们所需要的场景耗时，该5分钟应该是整个大场景（如从进站到离开），而我们通常所使用的场景往往包含了一连贯的子场景，如进站、等待、上车等，因此，如果我们测试的场景是某一个具体的动作，不建议采用这种公式（当然，如果单独为每个动作估算时间也是可以的。）
从本质上来说，两种公式的统计，结果都是一样的，关键取决与统计口径。
极限的问题也是我们需要考虑的，数据的估算往往是一个大的工程，涉及到很多复杂的情况，比如用户的进入与离开，人流异常等，因此我们考虑的多为常规的情况，在一些特殊的情况下，用户的峰值往往要大很多，此时需要去对极限情况下进行估算。
此时的目的在于检查系统的极限承载情况，如列车极限大承载2000人，站内极限承载10000人是一样的，超出这个极限，就需要采取一些紧急措施，比如限流（对应到普通的系统，就是设置特大连接数，超出的必须等待）之类。
这种值的计算，不可能给出准确值，可以根据实际情况，协商而定，比如把经验系数更改为5，这种情况下，如果有日志或者统计数据予以支撑，会更加精确。
● 回答客户的疑惑
面对客户，经常需要去解答一些问题，常见的几类疑惑如下：
1、客户坚持要求并发2000，怎么办？
这个问题非常关键，即上面所谓的阐述只是为了让大家对并发等概念有个大体的理解，但我们的工作重心不是一来就跟客户讲理论，而是合理、有效、迅速地完成项目，因此，特别是一些项目的咨询阶段，如果客户坚持提出达到某个并发要求，我们首先需要看下这个情况产品能否支持，如果不支持，用修改架构（比如增加服务器，公司的大部分产品都支持集群）来完成，如果还是没法达到要求，我们再来跟客户交流，从客户能理解的方式，从客户的角度去计算并发，然后得到认可就行了。当然，解决这些问题，需要我们对公司的产品性能基本比较了解（可以经过产品的性能测试报告来了解，质保将来会考虑出台所有产品的性能指标集合供参考），如果难度还是很大，可以申请质保的支持。大家一起去解决这个问题。
2、你们的系统能支持10000并发吗？
一些客户经常提出非常高的并发要求，此类客户通常对性能并不了解，或者之前有客户对其做了错误的解释，此时我们需要解释我们测试并发的概念：同时向服务器发出请求的虚拟用户数。（而我们通常会采用严格的方法进行场景测试：即采用集合点的方式进行操作。这种方式也即前面介绍的狭义并发的概念。）
另外，并发值需要考虑实际情况，需要根据实际的需求进行计算，与此同时，并发的影响因素并非仅仅是软件本身，还有网络、架构等等，TRS的产品性能测试往往给出单位机器的性能，用户可以根据这个基础值来构造实际架构。
3、你们的系统怎么才支持200并发？
并发的概念在于同时在处理某一件事情，而且系统一直保持这样的一个强度，并不是说总共只有200人，另外，我们测试的一般是单机，也就是说，如果更好的性能要求，可以用集群的方式来获得更优的结果，目前TRS的产品基本都支持集群的部署架构。需要注意的是，并发的支持除了软件本身，还受到网络、服务器性能等多方面原因的影响。
4、是否可以使用每秒处理事务来衡量。
性能测试的衡量指标除了响应时间，还有吞吐量、每秒点击数、每秒PV、每秒事务处理能力等，因此我们可以用多种方式进行衡量，在更大意义上，各个指标间也存在一定的内涵联系，结合起来考虑更能够检查系统的性能。但受制于一些客观原因（如定制），在之前的报告中，指标衡量存在一定的限制。
5、响应时间与并发、压力是什么关系？这么操作的响应怎么才6秒，太慢了，你们的产品性能不行啊！
一般的，一定的并发下将对系统造成一定的压力，而对每个并发（用户）而言，所体现出来的性能多是直观的响应时间，在环境一定的情况下，响应时间越快说明系统性能越好。但此处需要清除一个问题，假定一个用户获取的响应时间是5秒，这5秒都在对系统产生压力吗？
后面这个是一个有趣而有意义的问题，我们知道这个响应时间是从用户发出请求到接收到响应的为止的总耗时，如果我们使用httpwatch之类的工具，可以很清晰的看到时间消耗的分布区间，我们可以把这个问题比作是向墙壁击出一个球，从击出到弹回来的时间即为响应时间。
大家打过壁球吗？打壁球的过程其实就完美的诠释了用户发起请求到接受响应整个过程，可以我们可以把墙壁看作系统，打球者就是用户，球是用户发出的请求，击打一次球包含有三个动作：击出球、球接触墙壁、收到弹回的球。三个过程加起来的总时间就是这个请求（打出一发球）所得到的响应，但很显然，真正对系统产生压力的动作在于接触墙壁的时间，大部分的时间消耗在空中，即球在空中飞行时的时间，而这个飞行时间并不受系统控制，对应到常规系统，就很可能是网络在传输过程中出现了问题。
这个壁球的例子实际上还可以解释一些相关的概念，比如并发就是同时击出多个球，系统（墙壁）所能承受的极限并发压力就是墙壁的面积所能容纳的壁球数量，假定墙壁面积可以容纳1000个球，则墙壁瞬间可以接触的球的数量就是1000个，这个就是狭义并发的概念了，考虑到空中飞行，即将触碰墙壁的球，理论上的广义并发值要高于1000。击球时的力度可以理解为客户端的性能，性能好发球就快，否则就慢，只要系统性能没有达到瓶颈（比如墙壁没有坏），系统的性能是跟客户端呈正比的，即击球速度越快，返回越快。
因此，当遇到客户对响应时间有疑问时，我们需要解释的重点在于，压力在于球接触墙壁的瞬间，但性能测试考核的响应时间确实包含了两次飞行（发送与接受）的时间，而这个时间是受包含服务器性能、网络性能、客户端性能在内的多因素影响的，相信客户可以理解。
● 简单的结论
如果您觉得上面说的东西过于繁琐，以下基本概念可能更适合阅读。
1、并发分为狭义并发与广义并发两种，狭义并发指同一时间点开始做某件事情，广义并发指同一时间段正在做某件事情；
2、并发与被考察的场景是息息相关的，测试中所指的并发一般指同一时间段在做某件事情（被测事务）的用户数，在严格测试的环境下，我们会要求所有用户在同一时间点集合并执行；
3、在线用户与并发用户不是一个概念，在线用户包含了很多非测试事务用户、空闲的客户等，因此不能把在线的用户全计作并发用户，一般的并发用户占在线用户总量在10%～20%左右，当然，这个值仅供参考，实际问题需要实际分析。
4、理论上说并发越大性能越好，但其取决与很多因素，比如网络、服务器数量、服务器性能、系统架构、软硬件优化等，另外，并发的计算需要在需求阶段根据实际情况进行估算，这样得到的结果才是合理的。
5、几个概念的再次说明：
→ 并发用户数：同时在操作被考察事务的用户数
→ 在线用户数：当前被测系统中的活动用户数（包括考察事务与非考察事务）
→ 平均响应时间：每个用户操作事务获得的平均响应时间（算术平均值）
→ 90%响应时间：90%用户平均响应时间在此值范围内（取除去10%极高值后的极限值）
→ 平均事务数：单位时间完成的事务数（如登录、首页读取等）
→ 平均吞吐量：单位时间内的数据传输量
→ 平均点击数：单位时间完成的请求数量

→ PV：某时间段内完成的页面请求数量

教育联展————专业的软件测试咨询服务平台。
详询：王萍老师18988787201
详询：小文老师18988787201