web 性能测试中的几个关键指标(并发用户数,QPS,用户平均请求等待时间)
互联网 & 05-24 00:52:40 & 作者：佚名 &
关于并发用户数和QPS，自己一直被这两个概念纠结，阅读了一下相关资料，总结如下
并发用户数和QPS两个概念没有直接关系，但是如果要说QPS时，一定需要指明是多少并发用户数下的QPS，否则豪无意义，因为单用户数的40QPS和20并发用户数下的40QPS是两个不同的概念。前者说明该应用可以在一秒内串行执行40个请求，而后者说明在并发20个请求的情况下，一秒内该应用能处理40个请求，当QPS相同时，越大的并发用户数，代表了网站并发处理能力越好。对于当前的web服务器，其处理单个用户的请求肯定戳戳有余，这个时候会存在资源浪费的情况（一方面该服务器可能有多个cpu，但是只处理单个进程，另一方面，在处理一个进程中，有些阶段可能是IO阶段，这个时候会造成CPU等待，但是有没有其他请求进程可以被处理）。而当并发数设置的过大时，每秒钟都会有很多请求需要处理，会造成进程（线程）频繁切换，反正真正用于处理请求的时间变少，每秒能够处理的请求数反而变少，同时用户的请求等待时间也会变大，甚至超过用户的心理底线。所以在最小并发数和最大并发数之间，一定有一个最合适的并发数值，在并发数下，QPS能够达到最大。但是，这个并发并非是一个最佳的并发，因为当QPS到达最大时的并发，可能已经造成用户的等待时间变得超过了其最优值，所以对于一个系统，其最佳的并发数，一定需要结合QPS，用户的等待时间来综合确定。图1 并发用户数，QPS，用户平均等待时间（响应时间关系图） 上面这张图是应用其他人的关于并发用户数，QPS，用户平均等待时间的一张关系图，对于实际的系统，也应该是对于不同的并发数，进行多次测试，获取到这些数值后，画出这样一张图出来，以便于分析出系统的最佳并发用户数。
大家感兴趣的内容
12345678910
最近更新的内容您所在的位置：
性能测试解惑之并发压力（二）
性能测试解惑之并发压力（二）
发布时间：
编辑：zhangck77
来源：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代表在线用户，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：某时间段内完成的页面请求数量
教育联展————专业的软件测试咨询服务平台。
详询：王萍老师
详询：小文老师
课程精选：
编辑推荐ditor recommend
软件测试在线报名
请选择城市
本周热门点击
考试答疑微信
版权所有 深圳市诺达教育股份有限公司 (C) www.thea.cn All Rights Reserved 粤ICP备号-3性能测试知多少---并发用户
　　在做的时候，我们常常听到并发用户、响应时间、吞吐量专业术语，也许大家都理解，这里有一个理解的层次与深度概念。最近有看断念《软件性能详解与案例分析》一书，看了他的讲解，原来我对这些术语的理解还是比较肤浅，其实，这里也主要受制于自己的知识面。所以，再拿出来与大家重温一下。
　　ps：按照惯例先上个图，因为看纯文字的比较累！^_^
　　并发用户数
　　大家都知道我们的性能测试就通过工具模拟多用户对系统进行操作，对系统造成压力，来验证系统的性能（不太标准的解释）。好多人也简单的把性能测试当成并发测试。那么这个&多用户&和&同时&两个因素缺一不可。只多用户不同时，很难对系统构成压力；没有多个用户，同时的概念也就自然不存在了
　　并发的两种情况
　　一种是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，这种操作一般指做同一类型的业务。比如，所有用户同一时刻做并发登陆，同一时刻做表单提交。
　　另外一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的。比如，在同一时刻有用户在登录，有用户在提交表单。
　　从服务器的角度来看并发
　　前面的两种解释都是从用户业务的角度来解释并发的，因为我们平时所做的性能测试也是从用户端对业务层的操作来进行并发测试的。
　　如果考虑整个系统运行过程中服务器所承受的压力是这样的：在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上，都有一个&同时向服务端发送请求的客户数&，这个就是所谓的服务器所承受的最大并发访问数。
　　真正意义上的并发不存在
　　上谈了这么多并发，现在又说真正意义上的并发不存在。何解？学原理的同学都知道，CPU在一个时间点上只能干一件事儿。为什么我们可以边看电影，边打字，边语音。因为CPU很快很快，他可以处理一下电影，再处理一下打字，再处理一下语音。因为它很快，所以，它可以在多个程序之间快速瞬间的切换，给你造成的假象就是它在同时做这些事情。（现在的双核、四核的CPU另说）
　　那么我们的系统在接到用户的请求后也要调用CPU来完成某些处理，然后返回给用户。那么我们对系统有做并发测试是测什么呢？举个简单的例子。假如有一位神医，他的看病速度非常快，假设他的看病速度是不变的；然后有一群接待人员来接待看病的客人，有成千上万的病人来看病，接待人员要想各种办法来做好接待，使病人更快的看到病。比如，可以事先咨询病人得的什么病，然后将病人进行分类，比如可以扩大接待室，让更多的病人可以进到医院来看病等。
　　神医就是我们的CPU，接待人员就是我们的系统，病人就用户，我们做性能测试的目的就是了解接待人员哪个地方给医院看病造成了瓶颈。只来一个病人，医院的看病速度与服务很好。一下子来十万个病人各种问题就出来了。接待人员的服务态度下降，多余的人员跟本进不到医院去，医院的洗手间不够用，造成病人无法上则所而离开，这些都属于系统问题。所以，我们一般测试的目的是看医院的接待能力。
　　系统用户数与同时在线人数
　　在实际的性能测试中，经常接触到与并发用户相关的概念还有&系统用户数&与&同时在线人数&下面通过一个实例来描述他们之间的差别。
　　假设有一个网站，注册用户才能登录使用各种功能，如上传头像，阅读专家文章等。该系统有20万注册用户，这就是说有20万用户可以使用这个网站的所有功能，20万就是这个网站的&系统用户数&，网站有一个在线统计功能，从统计数据中可以看到，同时登录网站的人数的最高记录是2万，就是有2万人同时用浏览器打开着这个网站。2万就是&同时在线人数&
　　那么系统的并发用户数是多少呢？2万么？NO！这2万只表示在系统最高峰时有这么多用户登录了网站，并不表示实际服务器的承受压力。因为服务器承受压力还与具体的用户访问模式相关，在这2万用户中考察某一个时间点对用户发出请求数，可以会大大缩水。那么，该系统的服务端承受的最大并发访问数是多少呢？这个取决于业务并发用户数和业务场景，一般可以通过服务器的分析得到。
　　求并发用户数公式
　　在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务的角度关注应该设置多少个并发数比较合理。
　　下面找一个典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人，平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。
　　C==166.7
　　C表示平均并发用户数，那么对这个签到系统每秒的平均并发用户数为166
　　当然，在性能测试上，任何公式都不是严谨的，最重要的是对系统做出有效正确的分析。
阅读(...) 评论()没有更多推荐了，
不良信息举报
举报内容：
性能測試——并发用户数估算
举报原因：
原文地址：
原因补充：
最多只允许输入30个字
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！查看: 8241|回复: 4
关于并发用户数的思考-通过PV量换算并发
该用户从未签到
首先介绍一下pv量：
PV(访问量)：即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次。
UV(独立访客)：即Unique Visitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户
端只被计算一次。
IP(独立IP)：即Internet Protocol,指独立IP数。00:00-24:00内相同IP地址之被计算一次。
***************************
问题：一个系统的日均pv量是8000，那么并发用户数应该是多少?
1、首先，我觉得应该考察这个系统的业务都有什么，各个之间有什么关联性。这些PV都分布在哪里业务上。
2、如果这些pv为单一业务，那么还要看用户在前台的一次操作，会对服务器端产生几个请求。因为如果网页中包含图片、js等内容，用户一次打开操作，会对服务器产生多个操作。
3、我们假设用户在前台的一次操作，仅产生一次pv。用户并发数是指多少用户同时对服务器产生访问。对此，我假设了三种访问情况：
& & （1）最差情况：8000个用户同时发起请求，那么并发用户数应为8000
& & （2）最好情况：8000个用户在时间上均匀地发起请求。那么并发用户数为*60=0.093。折合一分钟内之有5.5个请求，基本上就没有并发，只是单个执行。
& & （3）80~20原则：但是在现实生活中，以上两种情况发生的概率很小。根据统计学原理，采用80~20原则计算并发用户数。
& && && && & /（8*60*60*0.2）=1.11，即每秒中有两个用户并发。
& && && & 可能有人会问：为什么是每秒多少个用户，不是每小时、每分钟、每毫秒？
& && && & 回答：我做一个120人并发查询的项目，响应时间最小0.047s，最大6.216s，平均0.779s。与服务器的一次业务交互，大约需要1秒钟。
& && && &个人感觉，以小时、分钟做单位，时间跨度太长；以毫秒做单位，时间跨度又太短。综上所述，以秒为单位比较合适。
4、lr使用集合点后，每次迭代中，必须全部（或部分）请求得到回复后，才发起下次迭代。所以在迭代周期内我们只发送了一次并发请求，我们在根据80~20原则计算得出的并发用户数，还要乘以这个迭代周期。
& && &例如我的查询项目中，迭代周期大约为9秒，所以并发用户数为1.11*9=9.99,最终得到并发用户数为10个
个人观点，如有不妥之处，请指正
TA的每日心情郁闷 16:54签到天数: 3 天连续签到: 2 天[LV.2]测试排长
2 8原则是好，有不明白的，能在详细一些就好了！
/（8*60*60*0.2）=1.11&&比如 这个例子中，8000是什么？0.8是什么？8*60*60*0.2又是什么？ 我能明白些，有些新手不太了解！劳驾楼主能在详细一下介绍嘛！
该用户从未签到
& & 8000是并发的访问数，80~20原则是指80%的工作量会集中在20%的时间内完成，所以用户访问系统不是平均，而是集中在某一段时间内。0.8是指取并发量的80%，0.2是指取工作时间的20%，8*60*60是指每天8小时，每小时60分，每分钟60秒，就是指每天的工作时间折成秒
TA的每日心情开心 09:54签到天数: 1 天连续签到: 1 天[LV.1]测试小兵
计算出的这个并发数量10，有何意义？用作哪种指标？
TA的每日心情开心 09:20签到天数: 1 天连续签到: 1 天[LV.1]测试小兵
迭代周期是指什么意思
站长推荐 /3
了解自己的心里圈，学习不同的内容，让自己由内而外强大起来！
【活动时间】：每个工作日的周一至周五(AM:10:00~PM:5:00)
缺乏亮眼的项目经验？面试“BAT”没信心？升职加薪无望？——《大型电商项目自动化测试框架开发》直播课，手把手教你写框架开发，6.28开课！
Powered by}