在线人数、并发人数及 TPS

大家好，欢迎来到IT知识分享网。

在线人数与并发人数

• 在线用户数：用户同时在一定时间段的在线数量
• 并发用户数：某一时刻同时向服务器发送请求的用户数

一般而言，我们习惯以5-20的比率来推算并发用户与在线用户之间的关系。即，并发与在线的比例约为5%-20%。

在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别：

假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？

根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。

公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。

公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

实例：
假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。

则根据公式（1）和公式（2），可以得到：
C = 4004/8 = 200
C’≈200+3根号200 = 242

并发人数与 TPS

1. 背景

在做性能测试的时候，很多人都用并发用户数来衡量系统的性能，觉得系统能支撑的并发用户数越多，系统的性能就越好；对TPS不是非常理解，也根本不知道它们之间的关系，因此非常有必要进行解释。

2. 术语定义

• 并发用户数：指的是现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)，注意并发用户数跟注册用户数、在线用户数有很大差别的，并发用户数一定会对服务器产生压力的，而在线用户数只是 ”挂” 在系统上，对服务器 不产生压力，注册用户数一般指的是数据库中存在的用户数。
• TPS：Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标。

3. Vu和TPS换算

• 简单例子：在术语中解释了TPS是每秒事务数，但是事务时要靠虚拟用户做出来的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生 1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。
• 复杂公式：
  试想一下复杂场景，多个脚本，每个脚本里面定义了多个事务（例如一个脚本里面有100个请求，我们把这100个连续请求叫做Action，只有第10个请求，第20个请求分别定义了事务10和事务20）具体公式如下：

符号代表意义：
Vui表示的是第i个脚本使用的并发用户数
Rtj表示的是第i个脚本第j个事务花费的时间，此时间会影响整个Action时间
Rti表示的是第i个脚本一次完成所有操作的时间，即Action时间
n 表示的是第n个脚本
m 表示的是每个脚本中m个事务

那么第j个事务的TPS = Vui/Rti

4. 如何获取Vu和TPS

• 并发用户数(Vu)获取
  新系统：没有历史数据作参考，只能通过业务部门进行评估。
  旧系统：对于已经上线的系统，可以选取高峰时刻，在一定时间内使用系统的人数，这些人数认为属于在线用户数，并发用户数取10%就可以了，例如在半个小时内，使用系统的用户数为10000，那么取10%作为并发用户数基本就够了。
• TPS获取
  新系统：没有历史数据作参考，只能通过业务部门进行评估。
  旧系统：对于已经上线的系统，可以选取高峰时刻，在5分钟或10分钟内，获取系统每笔交易的业务量和总业务量，按照单位时间内完成的笔数计算出TPS，即业务笔数/单位时间（560或1060）

5. 如何评价系统的性能

针对服务器端的性能，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能，如果必须要用并发用户数来衡量的话，需要一个前提，那就是交 易在多长时间内完成，因为在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到脚本中，并发用户数基本可以增加一倍，因此用并发用户 数来衡量系统的性能没太大的意义。

6. 相关案例

通过大量性能测试我们发现不需要用上万的用户并发去进行测试，只要系统处理业务时间足够快，几百个用户甚至几十个用户就可以达到目的。另外咨询很多专家做过的性能测试项目，基本都没有超过5000用户并发。

因此对于大型系统、业务量非常高、硬件配置足够多的情况下，5000用户并发就足够了；对于中小型系统，1000用户并发就足够了。

7. 性能测试策略

做性能测试需要一套标准化流程及测试策略，并发用户数只是指标考虑的一个，在做负载测试的时候，一般都是按照梯度施压的方式去加用户数，而不是在没有预估的情况下，一次加几万个用户，交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内，这样做没有多大的意义，这就好比“有多少钱可以干多少事”一样，需要选择相关的策略。

8. Loadrunner VS PTS

从下图对比项可以看出，PTS比Loadrunner(LR)更能让客户接受。

9. 总结

• 系统的性能由TPS决定，跟并发用户数没有多大关系。在同样的TPS下，可以由不同的用户数去压（通过加思考时间设置）。
• 系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。
• 建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。
• 一般情况下，大型系统（业务量大、机器多）做压力测试，5000个用户并发就够了，中小型系统做压力测试，1000个用户并发就足够了。

参考：