在性能领域中，我们经常用并发用户数来判断一个系统是否达到性能需求，比如说用“系统支持 1000 用户”这样的描述来说明性能需求。但是并发是怎么个并发法？它和 TPS 之间是什么关系？并发用户数和在线用户数又是什么关系呢？这样的问题长期以来困扰着性能工程师们。
在线用户和 TPS 之间的关系
单个在线用户的 TPS 计算
假设用户整个操作流程是从 23:16:50 到 23:21:00，时间窗口总共是 250 秒，请求总共是 100 个。但是我们通常都会设置事务的，这时我们就得来看看事务是怎么定义的了。
-
如果你把事务 T 设置为每个请求一个事务，那显然，你就不用计算了，一个用户需要的就是 0.4TPS。对应的 TPS 计算如下：1(用户)×100(请求数)÷250(时间窗口)≈0.4(请求数/秒)
-
如果你把事务定义到每个业务操作的级别，对应前面我们说的，总共是 7 个业务操作，而这 7 个业务操作是在 250 秒内完成的，那对应的 TPS 就是：1(用户)×7(单业务操作级事务)÷250(时间窗口)≈0.028(TPS)也就是说如果你把事务定义在业务操作级别，在这个示例中，一个用户就需要 0.028TPS。请注意，这里面的每一个事务的请求数并不一致哦。
-
如果你把事务定义到整个用户级别（通常情况下，业务部门会这样要求，因为只有做完了这些步骤才是一个业务完成了），那显然这 250 秒内只完成了 1 个事务。那对应的 TPS 就是：1(用户)×1(完整用户级事务)÷250(时间窗口)≈0.004(TPS)
把事务大小定义在不同级别时，我们得到的结果必然是不一样的。如果在项目中只是简单地说，性能需求是要达到多少多少 TPS 这样的笼统需求，就必然会导致不同的人理解的 TPS 内容不一样。如果有人让你实现 1000TPS，那你就要问，T 是什么级别的？请你注意，在这个逻辑中，我没有把业务模型加进来一起讨论，因为加了业务模型，反而会让问题变得更复杂。
多在线用户的 TPS 计算
假设系统有100000用户，全部在一个小时内完成的业务，如何计算TPS？
那如果是多个用户，操作指定不会都是 250 秒，所以我们只能假设系统中的 100000 用户都是平均 250 秒完成业务，那计算方式如下：
-
请求级的 TPS：(100000(用户)×100(请求数))÷3600(秒)≈2,777.78(TPS)
-
单业务操作级 TPS：(100000(用户)×7(业务操作)))÷3600(秒)≈194.44(TPS)
-
用户级 TPS：(100000(用户)×1(用户级)÷3600(秒)≈27.78(TPS)
通过这样的计算，我们就可以知道需要多少 TPS 来和在线用户对应。
峰值在线用户的 TPS 计算
上面是按一小时内所有的用户都平均分布的方式计算的，如果有峰值这个算法就不对了，这就是为什么我说要历史业务峰值的原因。
线上业务峰值的统计时间段越短，显然是越准确的。如果我们从生产上统计出来 10 万用户是在 1 小时内完成的。其中，1 万用户在 1 个小时内的某 1 分钟内完成业务。
这样的数据其实已经达到大型电商的秒杀级别了。那根据上面的计算方式，我们可以得到：
-
请求级的 TPS：(10000(用户)×100(请求数))÷60(秒)≈16,666.67(TPS)
-
单业务操作级 TPS：(10000(用户)×7(业务操作)))÷60(秒)≈1,166.67(TPS)
-
用户级 TPS：(10000(用户)×1(用户级)÷60(秒)≈166.67(TPS)想要得到精确的峰值 TPS，其实很明显的前提就是统计的时间段够不够精准。
并发用户和 TPS 之间的关系
从上面的在线用户计算示例中，相信你已经发现，在日志中两个操作之间的是有时间间隔的。那如果一个用户在操作的时候没有间隔，TPS 应该是多少呢？通过 JMeter 录制浏览器的行为，我们先从时间戳上来看，从第一个请求到最后一个请求，共有 100 个请求，总共用了 6 秒
实际上这里应该是用压力场景中的包括这些请求的平均响应时间）。同样地，我们来计算一下对应的 TPS。
请求级的 TPS：1(用户)×100(请求数)÷6(秒)≈16.67(TPS)
单业务操作级 TPS：1(用户)×7(业务操作)÷6(秒)≈1.17(TPS)
用户级 TPS：1(用户)×1(用户级)÷6(秒)≈0.17(TPS)
一个没有停顿的用户（并发用户）相当于多少个有停顿的用户（在线用户）呢？在这个转换的过程中，我们暂时不考虑请求的区别。
16.67÷0.4=1.17÷0.028=0.17÷0.004≈41.79（倍）
并发度就是：1(并发用户)÷41.79(在线用户)≈2.4%(也即是6/250)
如果你录制了脚本并且没有设置停顿时间（等待时间），并且你想支持的是 10 万在线用户在一小时内完成所有业务，那么支持的对应并发用户数就是：
100000(在线用户)×2.4%=2,400(并发用户)
我们一个线程跑出来的请求级的 TPS 是 16.67，要想模拟出 10 万用户的在线，我们需要的压力线程数就是：
2,777.78(10万在线用户时的请求级TPS)÷16.67(一个压力线程的请求级TPS)≈167(压力线程)
在线用户数和压力线程之间的关系：
-
用请求级 TPS 计算：压力线程=峰值采样时间段(在线用户数×单用户请求数)÷一个压力线程的请求级TPS
-
用单业务操作级 TPS 计算：压力线程=峰值采样时间段(在线用户数×单用户业务操作数)÷一个压力线程的业务操作级TPS
-
用用户级 TPS 计算：压力线程=峰值采样时间段(在线用户数×单用户完整业务数(也就是1)÷一个压力线程的用户级TPS
并发用户数的计算
并发用户数=在线用户数×有停顿时间的单线程TPS/无停顿时间的单线程TPS
并发度：并发度=在线用户并发用户×100%（取值要在同一时间段）
从以上的计算逻辑中，我们可以看到，这其中有几个关键数据：
-
在线用户数，这个值可以从日志中取到
-
在线用户数统计的时间段，这个值也可以从日志中取到
-
用户级操作的完整业务流时间（记得多采样一些数据，计算平均时间）。这个值也是从日志中取到；
-
无停顿时间的完整业务流时间。这个值从压力工具中可以取到；
-
单用户完整业务流的请求数。这个值可以从日志中取到。
用户思考时间的使用
有太多人想用思考时间来描述真实在线用户操作时的停顿，但是如果想用它，却没有那么容易。在前面的示例中，我们看到了一个用户的完整的业务流操作用了 250 秒，其中就包括了思考时间。对于这个用户来说是做了 7 个操作，但是每个操作之间实际上都是有间隔的。而这个时间间隔就是我们在性能脚本中经常说的思考时间（Think Time）。如果你想设置思考时间，就得把每两个操作之间的时间间隔拿到。并且不是只取一个用户的就够了，而是要把大量的真实用户的操作时间间隔拿到，然后再做平均值、标准方差的计算，最后再配置到压力工具中。在实际的工作经验中，几乎没有一家企业可以做到这一点的。因此在实际的性能工程中不要用思考时间了，因为即使用了也并不能说明他们模拟了真实用户的行为。