你知道并发用户数应该怎么算吗？

什么是并发

 并发数是 16TPS，就是 1 秒内整个系统处理了 16 个事务。

在线用户数、并发用户数怎么计算

 

 

 如上图所示，总共有 32 个用户进入了系统，但是绿色的用户并没有任何动作，那么显然，在线用户数是 32 个，并发用户数是 16 个，这时的并发度就是 50%。

但在一个系统中，通常都是下面这个样子的。

 

 为了能 hold 住更多的用户，我们通常都会把一些数据放到 Redis 这样的缓存服务器中。所以在线用户数怎么算呢，如果仅从上面这种简单的图来看的话，其实就是缓存服务器能有多大，能 hold 住多少用户需要的数据。

最多再加上在超时路上的用户数。如下所示：

 

 所以我们要是想知道在线的最大的用户数是多少，对于一个设计逻辑清晰的系统来说，不用测试就可以知道，直接拿缓存的内存来算就可以了。

假设一个用户进入系统之后，需要用 10k 内存来维护一个用户的信息，那么 10G 的内存就能 hold 住 1,048,576 个用户的数据，这就是最大在线用户数了。在实际的项目中，我们还会将超时放在一起来考虑。

但并发用户数不同，他们需要在系统中执行某个动作。我们要测试的重中之重，就是统计这些正在执行动作的并发用户数。

要想计算并发用户和在线用户数之间的关系，都需要有并发度。

 

 如果有 10000 个在线用户数，同时并发度是 1%，那显然并发用户数就是 100。

如果每个线程的 20TPS，显然只需要 5 个线程就够了（请注意，这里说的线程指的是压力机的线程数）。

这时对 Server 来说，它处理的就是 100TPS，平均响应时间是 50ms。50ms 就是根据 1000ms/20TPS 得来的（请注意，这里说的平均响应时间会在一个区间内浮动，但只要 TPS 不变，这个平均响应时间就不会变）。如果我们有两个 Server 线程来处理，那么一个线程就是 50TPS，这个很直接吧。

请大家注意，这里我有一个转换的细节，那就是并发用户数到压力机的并发线程数。

而我们通常说的“并发”这个词，依赖 TPS 来承载的时候，指的都是 Server 端的处理能力，并不是压力工具上的并发线程数。在上面的例子中，我们说的并发就是指服务器上 100TPS 的处理能力，而不是指 5 个压力机的并发线程数。

 

如果要有公式的话，这个计算公式将非常简单：

TPS=1000ms​∗压力机线程数/响应时间(单位ms)

对于压力工具来说，只要不报错，我们就关心 TPS 和响应时间就可以了，因为 TPS 反应出来的是和服务器对应的处理能力，至少压力线程数是多少，并不关键。

总结

通过示意图和示例，我描述了在线用户数、并发用户数、TPS（这里我们假设了一个用户只对应一个事务）、响应时间之间的关系。有几点需要强调：

通常所说的并发都是指服务端的并发，而不是指压力机上的并发线程数，因为服务端的并发才是服务器的处理能力。

性能中常说的并发，是用 TPS 这样的概念来承载具体数值的。

压力工具中的线程数、响应时间和 TPS 之间是有对应关系的。