在线用户数：用户同时在一定时间段的在线数量
并发用户数：某一时刻同时向服务器发送请求的用户数
一般而言，我们习惯以5-20的比率来推算并发用户与在线用户之间的关系。即，并发与在线的比例约为5%-20%
比如，某网站存在注册用户数为10W人，但同时在线最多1W人，但这1W个人，可能只有500人会浏览帖子，500人会进行发帖，只有这1000个人对服务器才有交易，那我们计算并发量的时候，就可以以1000为标准！
============================================================
昨天读完了段念写的《软件性能测试过程详解与案例剖析》一书的第一章，感觉学到了不少东西，以下将该书中的我认为是精华的一篇过来给大家一起看看：
在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。
假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？
根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。
在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。
（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
，请大家不要见笑，虽然上面写的都是很基础的东西，但是对我本人来讲，在还没有看这本书之前，这些概念我是特别模糊的。
=====================================================================
并发连接数、请求数、并发用户数
概念
并发连接数-SBC（Simultaneous Browser Connections）
并发连接数指的是客户端向服务器发起请求，并建立了TCP连接。每秒钟服务器链接的总TCP数量，就是并发连接数。
请求数-QPS（Query Per Second）/RPS（Request Per Second）
请求数有2个缩写，可以叫QPS也可以叫RPS。单位是每秒多少请求。Query=查询，也相当于请求。请求数指的是客户端在建立完连接后，向http服务发出GET/POST/HEAD数据包，服务器返回了请求结果后有两种情况：
- http数据包头包含Close字样，关闭本次TCP连接；
- http数据包头包含Keep-Alive字样，本次连接不关闭，可继续通过该连接继续向http服务发送请求，用于减少TCP并发连接数。
服务器性能怎么测？
通常情况下，我们测试的是QPS，也就是每秒请求数。不过为了衡量服务器的总体性能，测试时最好一起测试并发连接数和请求数。
测试原理
- 测试并发连接数采用每个并发1请求，多个并发进行；
- 测试请求数采用多并发、每个并发多个请求进行，总的请求数将会=并发数*单并发请求数，需要注意的是不同的并发和单并发请求数得出来的结果会不同，因此最好测试多次取平均值。
区分请求数意义何在？
大家打开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可以帮助开发者通过分布式并发压力测试，模拟指定区域和指定数量的用户同时访问，提前预知网站承载力。这就是云计算给我们带来的便利。