关于并发和吞吐量

Posted 2023-04-06

参考技术A 1、 在单接口压测时，我们用“请求总数/总时长”得到吞吐量；然后再用“吞吐量*平均响应时间”得到实际并发，此举可用来观察系统实际承受的并发；

2、 在多接口压测时，由于短板效应，同一个流程中的所有接口获得的请求总数和总时长都一样，显然“请求总数/总时长”计算各个子接口的吞吐量不合适，所以改用“并发/平均响应时间”，其中的并发数应在压测工具中埋点统计，不可简单使用工具线程数。

关于系统用户数，并发用户数，在线用户数，吞吐量

1、  关于系统用户数，并发用户数和在线用户数

系统用户数

侠义上来说，可以理解为系统注册用户数；广义上来说，可以理解为所有访问过系统的用户数

 

在线用户数

侠义上来说，可以理解为已登录系统的用户数；广义来说，可以理解为当前时间访问系统的用户数。

 

并发用户数

可以分两种：

1）同一时间点，执行同一（业务）操作的用户数

2）同一时间点，执行不同（业务）操作的用户数

 

注意：服务器实际承受的压力并不完全取决于并发用户数，详情见下面的例子。

 

例子（以51测试论坛为例）：

作为专业软件测试论坛，会有很多测试者去论坛注册帐号。

假设到现在已有75万在该论坛注册会员，那我们可以说，该论坛拥有75万的系统用户；

 

假设在某日早上9点，已有10万会员登陆了论坛，那么我们可以说，该论坛在某日9点时拥有10万的在线用户；

 

假设在这10万已登陆会员中，某个时间点，有2万会员正在提交新帖子，有3万会员正在编写帖子(假设编写帖子不会产生服务器请求操作)；有1万会员在帖子页面浏览某帖子内容；有1万会员正在发呆，啥也不做；还有3万会员正在点击某个帖子，那么我们可以说，某时间点，有2万个并发用户在提交新帖子，有3万个并发用户在编写帖子，有1万个并发用户浏览帖子内容，有3万个并发用户在点击某个帖子，，系统有9万的并发用户。

 

值得注意的是，这9万并发用户中，真正对系统产生压力的只有5万用户，即提交新帖和点击帖子的用户。换句话说，仅对系统发起了请求的并发用户才会对系统施加压力。

 

这也告诉我们，要好好测试一个系统的性能，必须先对用户的(业务)操作进行分析，分离出用户最常使用、最关心的（业务）操作，因为使用这些操作的人多，所以容易产生并发的情况。

 

计算公式：

   (1)

其中，C 是平均并发用户数；n是 login session的数量；L是login session的平均时长。T是考查的时间段长度。

注：login session指用户从登陆系统到退出系统之间的时间段。

 

Cmax ≈ C + 3   （2）

其中，Cmax 是并发用户数的峰值；C为公式（1）中的并发用户数。

 

注意：

1.公式的得出是假设用户login session产生符合泊松分布而估算得到的。

2.因为要精确估算平均用户数和login session的长度并不容易，同时用户的业务操作存在一定的时间分布，所以上述公式可能并不是很精确

3.基于第2点的建议：1)基于更细粒度的时间进行考察；2）考虑业务操作时间分布

 

2、吞吐量

性能测试中，可以侠义的理解为“单位时间内系统处理的用户请求的数量”。一般情况，吞吐量用请求数/秒、页面数/秒来衡量，从业务的角度，吞吐量也可用单位时间内的访问人数、处理的业务数等进行衡量。从网络角度来，也可以单位时间内的处理的数据量等进行衡量。

 

例如，

对于一个Web应用系统来说，从系统的处理能力考虑，可以以页面数/秒作为吞吐量的标准；对一个银行的前台业务来说，可以以其单位时间内处理的业务数作为吞吐量的标准。

 

通常，对于交互式应用，用户直接的体验是“响应时间”，通过“并发用户数”和“响应时间”可以确定系统的性能规划；但对于非交互式应用，用“吞吐量”来描述我们对系统性能的期望可能更加合理。

 

作为性能测试的主要关注指标，吞吐量和并发用户数之间存在一定的联系，在没有遇到性能瓶颈的时候，吞吐量可以采用如下公式计算：

其中，F表示吞吐量， N_vu表示虚拟用户数，R表示每个虚拟用户数发起的请求数，T表示性能测试所用的时间。

 

注意：虽然吞吐量指标可被看作是系统承受压力的体现，但是不同并发用户数量的情况下，对同一个系统施加相同的吞吐量压力，很可能会得到不同的测试结果。