在线用户数:用户同时在必定时间段的在线数量数据库
并发用户数:某一时刻同时向服务器发送请求的用户数浏览器
通常而言,咱们习惯以5-20的比率来推算并发用户与在线用户之间的关系。即,并发与在线的比例约为5%-20%安全
好比,某网站存在注册用户数为10W人,但同时在线最多1W人,但这1W我的,可能只有500人会浏览帖子,500人会进行发帖,只有这1000我的对服务器才有交易,那咱们计算并发量的时候,就能够以1000为标准!服务器
-----------------------------------------------------------------------------------------------------------------------------session
昨天读完了段念写的《软件性能测试过程详解与案例剖析》一书的第一章,感受学到了很多东西,如下将该书中的我认为是精华的一篇过来给你们一块儿看看:
并发
在实际的性能测试中,常常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”,下面用一个实际的例子来讲明它们之间的差异。app
假设有一个OA系统,该系统有2000个使用用户——这就是说,可能使用该OA系统的用户总数是2000名,这个概念就是“系统用户数”,该系统有一个“在线统计”功能(系统用一个全局变量记数全部已登陆的用户),从在线统计功能中能够获得,最高峰时有500人在线(这个500就是通常所说的“同时在线人数”),那么,系统的并发用户数是多少呢?分布式
根据咱们对业务并发用户数的定义,这500就是整个系统使用时最大的业务并发用户数。固然,500这个数值只是代表在最高峰时刻有500个用户登陆了系统,并不表示实际服务器承受的压力。由于服务器承受的压力还与具体的用户访问模式相关。例如,在这500个“同时使用系统”的用户中,考察某一个时间点,在这个时间上,假设其中40%的用户在较有兴致地看系统公告(注意:“看”这个动做是不会对服务端产生任何负担的),20%的用户在填写复杂的表格(对用户填写的表格来讲,只有在“提交”的时刻才会向服务端发送请求,填写过程是不对服务端构成压力的),20%部分用户在发呆(也就是什么也没有作),剩下的20%用户在不停地从一个页面跳转到另外一个页面——在这种场景下,能够说,只有20%的用户真正对服务器构成了压力。所以,从上面的例子中能够看出,服务器实际承受的压力不仅取决于业务并发用户数,还取决于用户的业务场景。工具
在实际的性能测试工做中,测试人员通常比较关心的是业务并发用户数,也就是从业务角度关注究竟应该设置多少个并发数比较合理,所以,在后面的讨论中,也是主要针对业务并发用户数进行讨论,并且,为了方便,直接将业务并发用户数称为并发用户数。post
(1) 计算平均的并发用户数: C = nL/T
(2) 并发用户数峰值: C’ ≈ C+3根号C
公式(1)中,C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度。
公式(2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式(1)中获得的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算获得的。
实例:
假设有一个OA系统,该系统有3000个用户,平均天天大约有400个用户要访问该系统,对一个典型用户来讲,一天以内用户从登陆到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。
则根据公式(1)和公式(2),能够获得:
C = 400*4/8 = 200
C’≈200+3*根号200 = 242
,请你们不要见笑,虽然上面写的都是很基础的东西,可是对我本人来说,在尚未看这本书以前,这些概念我是特别模糊的。
=====================================================================
并发链接数、请求数、并发用户数
并发链接数指的是客户端向服务器发起请求,并创建了TCP链接。每秒钟服务器连接的总TCP数量,就是并发链接数。
请求数有2个缩写,能够叫QPS也能够叫RPS。单位是每秒多少请求。Query=查询,也至关于请求。请求数指的是客户端在创建完链接后,向http服务发出GET/POST/HEAD数据包,服务器返回了请求结果后有两种状况:
一般状况下,咱们测试的是QPS,也就是每秒请求数。不过为了衡量服务器的整体性能,测试时最好一块儿测试并发链接数和请求数。
你们打开Chrome浏览器,按下F12,切换到Network选项卡,随便打开一个网页,按下F5刷新,将会看到刷刷一堆的请求。这里给出某大牛收集来的不一样浏览器产生的单站点并发链接数:
浏览器 | HTTP 1.1 | HTTP 1.0 |
---|---|---|
IE 6,7 | 2 | 4 |
IE 8 | 6 | 6 |
Firefox 2 | 2 | 8 |
Firefox 3 | 6 | 6 |
Safari 3, 4 | 4 | 4 |
Chrome 1,2 | 6 | ? |
Chrome 3 | 4 | 4 |
Opera 9.63,10.00alpha | 4 | 4 |
以Chrome为例,假设服务器设置的是Close(非持久链接),浏览器打开网页后,首先打开4个并发加载数据,在这些请求完成后关闭4个链接,再打开4个并发链接加载数据。也就是说,并非这个网页有100个请求就会产生100并发,而是4个并发链接并行。假设服务器设置的是keep-alive(持久链接),浏览器打开网页后,首先打开4个并发加载数据,在这些请求完成后不关闭链接,而是继续发出请求,节约从新打开链接的时间。
看到这里相信你已经知道答案了,这个问题无解,根据网页的内容大小和单网页的请求数和服务器的配置而定,这个数据的浮动值很是大因此没法测量。所以能承诺保证多少用户在线就是坑爹的主机商!
并发用户数量,有两种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的所有用户的数量,理由是这些用户可能同时使用系统;还有一种比较接近正确的观点是把用户在线数量理解为并发用户数量。实际上,在线用户不必定会和其余用户发生并发,例如正在浏览网页的用户,对服务器是没有任何影响的。可是,用户在线数量是统计并发用户数量的主要依据之一。
并发主要是针对服务器而言,是否并发的关键是看用户操做是否对服务器产生了影响。所以,并发用户数量的正确理解为:在同一时刻与服务器进行了交互的在线用户数量。这些用户的最大特征是和服务器产生了交互,这种交互既能够是单向的传输数据,也能够是双向的传送数据。
并发用户数量的统计的方法目前尚未准确的公式,由于不一样系统会有不一样的并发特色。例如OA系通通计并发用户数量的经验公式为:使用系统用户数量*(5%~20%)。对于这个公式是没有必要拘泥于计算的结果,由于为了保证系统的扩展空间,测试时的并发用户数量要稍微大一些,除非是要测试系统能承载的最大并发用户数量。举例说明:若是一个OA系统的指望用户为1000个,只要测试出系统能支持200个并发用户就能够了。
===============================================================================
近日,Hitest在其技术博客上发表了一篇题为《并发用户数与TPS之间的关系》的文章,文章对TPS和并发用户数作了详细的解释,并针对性能测试中系统性能的衡量维度和测试策略给出了本身的建议。Hitest是阿里巴巴技术质量部提供的一款Web&移动应用安全测试SaaS化服务平台,旨在帮助开发者简单快捷地进行安全测试。
在文中,做者首先对并发用户数和TPS作了解释:
并发用户数:是指现实系统中操做业务的用户,在性能测试工具中,通常称为虚拟用户数(Virutal User)。并发用户数和注册用户数、在线用户数的概念不一样,并发用户数必定会对服务器产生压力的,而在线用户数只是 ”挂” 在系统上,对服务器不产生压力,注册用户数通常指的是数据库中存在的用户数。
TPS:Transaction Per Second, 每秒事务数, 是衡量系统性能的一个很是重要的指标。
做者认为如今不少从业人员在作性能测试时,都错误的认为系统能支撑的并发用户数越多,系统的性能就越好。要理解这个问题,首先须要了解TPS和并发用户数之间的关系:
TPS就是每秒事务数,可是事务是基于虚拟用户数的,假如1个虚拟用户在1秒内完成1笔事务,那么TPS明显就是1;若是某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务,TPS就是1000了;若是某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务,要想达到1000TPS,至少须要1000个用户;所以能够说1个用户能够产生1000TPS,1000个用户也能够产生1000TPS,无非是看响应时间快慢。
也就是说,在评定服务器的性能时,应该结合TPS和并发用户数,以TPS为主,并发用户数为辅来衡量系统的性能。若是必需要用并发用户数来衡量的话,须要一个前提,那就是交易在多长时间内完成,由于在系统负载不高的状况下,将思考时间(思考时间的值等于交易响应时间)加到脚本中,并发用户数基本能够增长一倍,所以用并发用户数来衡量系统的性能没太大的意义。
做者最后作了综述,他认为在性能测试时并不须要用上万的用户并发去进行测试,若是只须要保证系统处理业务时间足够快,几百个用户甚至几十个用户就能够达到目的。据他了解,不少专家作过的性能测试项目基本都没有超过5000用户并发。所以对于大型系统、业务量很是高、硬件配置足够多的状况下,5000用户并发就足够了;对于中小型系统,1000用户并发就足够了。
性能测试须要一套标准化流程及测试策略,在实际测试时咱们还须要考虑其它方面的问题,好比如何模拟成千上万来自不一样地区用户的访问场景、如何选用合适的测试软件。性能测试对一些小的团队来讲并不是易事,不过前段时间阿里云发布了性能测试服务PTS,PTS能够帮助开发者经过分布式并发压力测试,模拟指定区域和指定数量的用户同时访问,提早预知网站承载力。这就是云计算给咱们带来的便利。