来源自极客时间的《高楼的性能工程实战课》
比如一个用户的某个操作,有
1、
如果你把事务 T 设置为每个请求一个事务,那显然,你就不用计算了,一个用户需要的
就是 0.4TPS。对应的 TPS 计算如下:
1( 用户 ) × 100( 请求数 ) ÷ 250( 时间窗口 ) ≈ 0.4( 请求数 / 秒)
2、
1( 用户 ) × 100( 请求数 ) ÷ 250( 时间窗口 ) ≈ 0.4( 请求数 / 秒)
2、
如果你把事务定义到每个业务操作的级别,对应前面我们说的,总共是 7 个业务操作,
而这 7 个业务操作是在 250 秒内完成的,那对应的 TPS 就是:
2.
1(
用户
) × 7(
单业务操作级事务
) ÷ 250(
时间窗口
) ≈ 0.028(
TPS)
也就是说如果你把事务定义在业务操作级别,在这个示例中,一个用户就需要
0.028TPS。请注意,这里面的每一个事务的请求数并不一致哦。
3、
3、
如果你把事务定义到整个用户级别(通常情况下,业务部门会这样要求,因为只有做完
了这些步骤才是一个业务完成了),那显然这 250 秒内只完成了 1 个事务。那对应的
TPS 就是:
1(
用户
) × 1(
完整用户级事务
) ÷ 250(
时间窗口
) ≈ 0.004(
TPS
)
![](https://i-blog.csdnimg.cn/blog_migrate/f61e50882be174046385f9a92802895f.png)
并发用户和
TPS
之间的关系
从时间戳上来看,从第一个请求到最后一个请求,共有 100 个请求,总共用了 6 秒(请你
注意这个响应时间,为了让你看得更清楚,我只截了一个用户的完整请求。实际上这里应
该是用压力场景中的包括这些请求的平均响应时间)。
同样地,我们来计算一下对应的 TPS
![](https://i-blog.csdnimg.cn/blog_migrate/a2cff2e6fb2dc500d31da0f4a96f5785.png)
注意,16.67/0.4中,这个0.4,是单用户一个请求中(上文)的0.4秒