05丨指标关系：你知道并发用户数应该怎么算吗？

        我在性能综述的那三篇文章中，描述了各种指标，比如 TPS、RPS、QPS、HPS、CPM 等。我也强调了，我们在实际工作的时候，应该对这些概念有统一的认识。

        这样的话，在使用过程中，一个团队或企业从上到下都具有同样的概念意识，就可以避免出现沟通上的偏差。

        我说一个故事。 

        我以前接触过一个咨询项目。在我接触之前，性能测试团队一直给老板汇报着一个数据，那就是 10000TPS。并且在每个版本之后，都会出一个性能测试报告，老板一看，这个数据并没有少于 10000TPS，很好。 后来，我进去一看，他们一直提的这个 10000TPS 指的是单业务的订单，并且是最基础的订单逻辑。那么问题来了，如果混合起来会怎么样呢？于是我就让他们做个混合容量场景，显然，提容量不提混合，只说单接口的容量是不能满足生产环境要求的。

        结果怎么样呢？只能测试到 6000TPS。于是我就要去跟老板解释说系统达到的指标是 6000TPS。老板就恼火了呀，同样的系统，以前报的一直是 10000TPS，现在怎么只有 6000TPS 了？不行，你们开发的这个版本肯定是有问题的。于是老板找到了研发 VP，研发 VP 找到了研发经理，研发经理找了研发组长，研发组长又找到了开发工程师，开发工程师找到了我。我说之前不是混合场景的结果，现在混合容量场景最多达到 6000TPS，你们可以自己来测。

        然后证明，TPS 确实只能达到 6000。然后就是一轮又一轮的向上解释。

        说这个故事是为了告诉你，你用 TPS 也好，RPS 也好，QPS 也好，甚至用西夏文来定义也不是不可以，只要在一个团队中，大家都懂就可以了。

        但是，在性能市场上，我们总要用具有普适性的指标说明，而不是用混乱的体系。

        在这里，我建议用 TPS 做为关键的性能指标。那么在今天的内容里，我们就要说明白 TPS 到底是什么。在第 3 篇文章中，我提到过在不同的测试目标中设置不同的事务，也就是 TPS 中的 T 要根据实际的业务产生变化。

        那么问题又来了，TPS 和并发数是什么关系呢？ 在并发中谁来承载”并发“这个概念呢？

        说到这个，我们先说一下所谓的“绝对并发”和“相对并发”这两个概念。绝对并发指的是同一时刻的并发数；相对并发指的是一个时间段内发生的事情。

        你能详细说一下这两个概念之间的区别吗？如果说不出来那简直太正常了，因为这两个概念把事情说得更复杂了。

什么是并发

        下面我们就来说一下“并发”这个概念。

        我们假设上图中的这些小人是严格按照这个逻辑到达系统的，那显然，系统的绝对并发用户数是 4。如果描述 1 秒内的并发用户数，那就是 16。是不是显而易见？

        但是，在实际的系统中，用户通常是这样分配的：

        也就是说，这些用户会分布在系统中不同的服务、网络等对象中。这时候”绝对并发“这个概念就难描述了，你说的是哪部分的绝对并发呢？

        要说积分服务，那是 2；要说库存服务，那是 5；要说订单服务，它自己是 5 个请求正在处理，但同时它又 hold 住了 5 个到库存服务的链接，因为要等着它返回之后，再返回给前端。所以将绝对并发细分下去之后，你会发现头都大了，不知道要描述什么了。

        有人说，我们可以通过 CPU 啊，I/O 啊，或者内存来描述绝对并发，来看 CPU 在同一时刻处理的任务数。如果是这样的话，绝对并发还用算吗？那肯定是 CPU 的个数呀。有人说 CPU 1ns 就可以处理好多个任务了，这里的 1ns 也是时