TPS如何转化为在线用户数？

2025-05-26 17:51 第二个卿老师阅读(60) 评论(0) 收藏举报

这篇文章来说说另外一个问题：TPS如何转化为在线用户数？

TPS如何转化为在线用户数

我们知道TPS是系统层面的参数，在线用户数是业务层面的参数，两者之间科学的转化需要数学建模与用户行为的简化，虽然有简化，但我们评估的正确趋势应该是系统处理能力比实际偏大，在线用户数比实际支持偏小。

名词解析

首先明确几个概念
TPS：反映的服务端的处理能力，即每秒处理的事务数
在线用户数：系统正常业务开展期间的使用用户数
并发用户数：在某个时间段对服务端发起负载的用户数
并发度：表示在线用户中有多少比例同时在发起请求
从上述概念引申可知：

TPS中的T如果是指的单个请求的事务，那么TPS = QPS，如果T是指业务事务（如2个请求），那么TPS=2QPS，如果T是指用户事务（如3个事务，共6个接口），那么TPS = 6QPS
在线用户数中，单个用户的业务流程可能不同？单个用户的业务操作间隔不同？多个用户使用系统的时间分布情况也不同？
并发用户数，统计的是一个时间段的用户，不是时间点。我们可以这样理解，假如用户均匀分布，每1s内有1个用户对服务端产生了负载，那么TPS = 1（T代表用户的事务），即并发用户数 = 1 = TPS
并发度，其分析需结合用户行为模型，并发度= 响应时间 /（响应时间 + 思考时间）× 100%，若用户平均每 10 秒完成一次操作（响应时间 2 秒 + 思考时间 8 秒），则活跃时间占比为 2/10=20%，即并发度为 20%。

在线用户数、并发用户数、并发度的关系

通过概念我们知道

并发用户数 = 在线用户数 * 并发度

于是，假如用户均匀分布，且服务端的处理能力TPS ≥ 1

如果每1s内有1个用户对服务端产生了负载，即并发用户数 = 1，并发度 = 1，在线用户数 = 并发用户数 / 并发度 = 1；
如果每1s内有2个用户对服务端产生了负载，即并发用户数=2，并发度=1，则在线用户数 = 并发用户数 / 并发度 = 2；
如果在线2个用户，每1s内仅1个用户对服务端产生了负载，即并发用户数=1，并发度=0.5，则在线用户数 = 并发用户数 / 并发度 = 2；
所以计算在线用户数需要先计算并发用户数与并发度，这里我们没有说到响应时间，是因为响应时间跟TPS有关，跟并发用户数是无关的

在线用户数与业务模型的关系

上述概念引申中，第2条说到，在线用户数在实际业务中有3个未知的问题，如何回答这三个问题？那就是业务模型

从数学的角度看，每个问题需要多次统计并建立数学模型，上述3个问题依次对应的是流量转化模型、用户行为模型、用户分布模型。而我们说的容量场景中的业务模型，其实就融合了上述三个数学模型。

所以只有我们建立了这3个数学模型，站在客户端的角度，我们也能模拟真实用户的负载情况，但现实是数学模型建立很难，模拟负载的不可控因素太多。
于是我们是否可以从服务端的角度进行设计，因为不管什么模型，到头来都是对服务端发起的请求，而请求都会有对应的后端日志记录。

流量转化模型

首先流量转化模型，应该是业务流的转化分布，对应到每个业务的请求数。

举例：电商的导购下单支付链路为：首页→商品详情→创建订单→订单支付→支付成功
那么可能100个用户访问首页，仅50个用户点击了商品详情，然后只有10个用户创建了订单，然后只有5个人对订单进行了支付。所以业务上看下单转化率为10%，支付转化率50%。

那么日志记录能解决流量转化模型吗？答案是可以的，我们根据业务场景的时间段，在日志记录中对统计该时间段各接口请求数的分布，就得到了流量转化模型

用户行为模型

我们知道用户行为模型，体现的是用户活跃度，代表了用户发起操作（请求）的间隔，而间隔是包括了接口响应时间与用户思考时间。

举例：电商的导购下单支付链路为：首页→商品详情→创建订单→订单支付→支付成功
那么1个用户访问首页，等待了5s再去点击商品详情，而另1个用户访问首页，等待了3s再去点击商品详情，依次类推，业务上看每个用户完成业务的时间总体是不一致的。

那么日志记录能解决用户行为模型吗？答案是未知的，因为目前的日志一般不直接标识接口是由那个用户请求的（而且HTTP请求是无状态的），当然不排除一些方法可以统计每个用户的操作间隔时间（比如第三方埋点、云工具），所以这是我们需要解决的一个问题。

用户分布模型

我们知道多个用户使用系统的时间段是不一样的，体现的是请求的集中情况，比如泊松分布、伽玛分布、正态分布等

举例：电商的导购下单支付链路为：首页→商品详情→创建订单→订单支付→支付成功
那么10点的时候有5个用户访问，11点的时候有100用户访问等等，业务上看，每个时间段的请求数不一致。

那么日志记录能解决用户分布模型吗？答案是可以的，我们可以统计业务中各业务请求的一天内请求数分布图，分析各业务请求峰值的时间段，如果多个业务请求的峰值时间段一致，那么这个时间段代表了请求的集中情况，可以作为场景分析，当然部分业务请求可能在其他时间段也突出，需要补充场景分析。

综上所属，站在后端角度，如果通过业务日志建模，需要解决用户行为模型，而用户行为模型主要提现在并发度上

并发度的计算

前面我们提到过并发度的计算公式

并发度= 响应时间 /（响应时间 + 思考时间）× 100%

由于并发度指的多个用户活跃时间在总周期时间的占比，那么在用户的操作周期中，上述的响应时间和思考时间应该是多个用户的平均时间

那么平均响应时间怎么计算呢
我们可以进行基准测试，获取系统空载时的单用户平均响应时间（事务为用户级）
那么响应时间+思考时间怎么计算呢
我们可能知道用户的总操作时间（如果有第三方埋点或统计工具），那么取多个用户的总操作时间平均值即可，也可以手动模拟业务，记录多次的平均值。

所以这里肯定存在误差，其中用户总操作时间评估越低，并发度越大，系统的处理能力要求也越高，也就大于实际系统处理的能力。

并发用户数的计算

根据上述用户分布模型，我们统计日志的峰值接口（用户）场景，这些场景对应的并发用户数正常也是最大的，在这个场景中我们知道了当前时间段的TPS（T为接口级事务），再结合业务流量转化模型，我们知道各业务请求在该场景的比例分布（对应转化率），那么我们就能估算并发用户数了，怎么估算呢？

首先我们需要分析日志数据，把各业务接口请求数及占总数比例统计到一个表格中，可能要屏蔽第三方的接口以及0.1%以下接口，具体操作可参考我之前的容量场景设计的文章，最后的表格大概如下：
然后梳理业务流程：
梳理各业务包含的接口，并得到主要业务流程，比如：用户进入首页--->用户登录--->点击商品详情--->点击去下单--->支付订单二维码
接着评估线上并发用户比例
按照上述业务流程，计算出当前业务场景的TPS下完整走完业务的用户比例（该用户比例本质上对应的是并发用户），但是上图我们会发现一个问题，用户登录的比例为0.25%，而下单saveOrder接口的比例为2%，为什么用户登录接口比下单还少？

分析原因：1.要么是用户提前登录了，我们统计的时间段还需要拉长。2. 要么是用户多次下单，导致saveOrder接口比例过大。
因为两者比例相差8倍，再结合业务情况分析，应该是第1个原因
那么我们拉长统计时间段后来计算，假如有15%的用户登录，只有2%的用户下单了
所以大概有2% / 15% ≈ 13%的用户会完整走完流程。

最后计算并发用户数
上述并发用户比例代表的活跃用户数中并发用户数占比，比如为13%，则100个TPS（一个T对应一次接口请求）可以支持13个并发用户，那么平均单个用户需要的TPS是：100 / 13 ≈ 7.69，通过容量场景测试，假如我们得到场景TPS为1000，那么系统支持的并发用户为：

并发用户 = 最大TPS / 单用户级TPS = 1000 / (100 / 13) ≈ 130

在线用户数的计算

上述两个步骤我们已经计算出了，并发度与并发用户数，那么在线用户数的计算为

在线用户= 并发用户 / 并发度 = 130 / 2% = 6500

该在线用户数作为估算值，有三处存在误差：

计算并发度时的平均业务流操作时间（思考时间+响应时间）存在误差，如果有统计工具可以很好解决这点
估算线上并发用户的比例存在误差，这里是判断业务场景下最大的并发用户数（该并发用户数是涵盖业务模型的）
统计容量场景的TPS存在误差，由于TPS包含了场景执行中的加速下降阶段，所以加速下降阶段占用的TPS比例要尽量小

总结

综上所述，计算在线用户数分为5步，公式如下

并发度 = 响应时间 /（响应时间 + 思考时间）× 100%
线上并发用户比例 = 总用户占比 / 完整业务的用户占比
单用户级TPS = 100 / 线上并发用户比例
并发用户 = 最大TPS / 单用户级TPS
在线用户= 并发用户 / 并发度

从以上的计算逻辑中，我们可以看到，这其中有几个关键数据：

无停顿时间的完整业务流时间（响应时间），这个值从压力工具中可以取到
用户级操作的完整业务流时间（响应时间+思考时间，计算多次采样的平均时间），这个值从日志中取到
线上峰值场景的TPS（T为接口级），这个值可以从日志中取到，并可以作为容量场景的SLA
线上峰值场景的总用户接口比例，一般为登录接口，这个值可以从日志中统计出
线上峰值场景的完整业务用户接口比例，一般选择体现具体业务的接口，这个值可以从日志中统计出
容量场景的TPS，这个值从压力工具中取到

刷新页面返回顶部

卿老师简单纯粹、谦虚谨慎