一台服务器能够支持的QPS(Queries Per Second)数量是一个很常见的问题。这是因为,当我们在设计和部署一个应用程序的时候,我们需要确保它能够处理足够的流量,以满足用户的需求。
在本文中,我们将探讨如何计算一台服务器能够支持的QPS。

计算一台服务器的QPS

首先,我们需要了解一下一台服务器的处理能力是如何衡量的。通常,我们会将服务器的处理能力表现为其每秒钟能够处理的事务数量。

每个事务都可以包含多个操作,例如读取数据、计算数据、写入数据等等。因此,我们可以将QPS定义为每秒钟能够执行的操作数量。

为了计算一台服务器能够支持的QPS,我们需要考虑以下几个个因素:

1. CPU: CPU是服务器最重要的资源之一。它负责执行所有的操作,并计算并响应客户端请求。因此,我们需要确保服务器具有足够的CPU处理能力来处理每个请求。
2. 内存: 内存是服务器另一个重要的资源。它存储了应用程序需要的数据,并被用于计算。我们需要确保服务器有足够的内存来支持每个请求。
3. 网络带宽: 如果我们的应用程序需要使用网络来与客户端交互,那么我们需要确保服务器拥有足够的网络带宽来支持高访问量。
4. 存储: 如果我们需要大量的数据存储,我们需要确保服务器有足够的存储空间来存储这些数据。

之后,我们可以通过简单的计算来计算一台服务器能够支持的QPS。例如,如果我们有一个4核、8GB内存的服务器,它每每秒钟可以执行2000个操作,那么它的QPS将是8000 (2000 *4)。

其中，每秒钟可以执行的操作，应该通过压测评估。可参考：97. 常用的HTTP服务压测工具

我们也可以反推一下上面的例子，每秒2000次操作，共四核，那么每核承接了500QPS，也就是每次操作只耗时2ms，这个估计是非常简单的业务逻辑了，毕竟2ms就处理完啦。

举个工作中实际的例子

有一个服务的QPS约20万（注：是服务下的所有接口QPS总和，而非某个特定接口），我们部署了约2000台服务实例（pod实现，可动态调整），每台实例统一规格为4核8G（统一后，方便评估扩缩容以及实例的替换迁移）。通过监控发现，每台实例承接了约100QPS，CPU和内存的使用率都在30%左右，属于一个健康的状态（达到60%时，我们配置了报警）。

同样，我们也可以反推一下，同样是4核8G，为什么第一个例子能承接8000QPS，而工作中这个实际例子只能承接100QPS呢？。

100QPS / 4核 = 25QPS，即每核承接25QPS，1s / 25QPS = 40ms，这与我们监控显示的是差不多的。因此知道了，工作中这个例子是业务逻辑复杂很多，每次请求的平均耗时为40ms，远大于第一个例子中的2ms。

实际上，从具体接口来看，有些接口业务逻辑简单，可能几ms就返回了，有些接口逻辑复杂，需要上百ms来处理，不过，整体上平均下来是40ms，而我们要估计的是一台实例能承接的QPS，即该服务实例上所有接口的流量，那么就是以这个40ms为准。