每秒查询率

QPS（Queries Per Second）即每秒查询率，是指一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。QPS是衡量服务器性能的重要指标，特别是在高并发场景下，它直接反映了服务器在单位时间内处理请求的能力，关系到系统的稳定性和用户体验。

QPS的计算方法

总体 QPS 之计算：总体 QPS 乃是指整个系统于某段时间内所处理请求数量的均值。其计算公式为：QPS = 总请求数 / 时间段（秒）。譬如，倘若在 1 分钟内系统处理了 3000 个请求，那么 QPS = 3000 / 60 = 50 QPS 。

特定接口/服务的 QPS 计算：特定接口抑或服务的 QPS 系指在一段时间当中，该接口或服务所处理请求数量的平均值。其计算公式同样为：QPS = 接口的总请求数 / 时间段（秒）。

QPS与TPS的区别

• TPS（Transactions Per Second）：每秒事务数，指每秒处理的事务数目。一个事务是指客户端向服务器发送请求然后服务器做出反应的过程。
• QPS与TPS的区别：对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求可计入QPS之中。例如，访问一个Index页面会请求服务器3次（一次html,一次css,一次js），那么访问这一个页面就会产生一个TPS，产生三个QPS。

QPS的应用场景和重要性

QPS主要用于衡量服务器查询的性能指标，如DNS服务器。它不包含复杂的业务逻辑处理，主要用于统计简单的查询操作。在高并发环境下，准确计算QPS对于评估和优化系统性能至关重要，直接关系到系统的稳定性和用户体验。

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

在本文中,我们将探讨如何计算一台服务器能够支持的QPS。

计算一台服务器的QPS

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

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

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

CPU: CPU是服务器最重要的资源之一。它负责执行所有的操作,并计算响应客户端请求。因此,我们需要确保服务器具有足够的CPU处理能力来处理每个请求。

内存: 内存是服务器另一个重要的资源。它存储了应用程序需要的数据,并被用于计算。我们需要确保服务器有足够的内存来支持每个请求。

网络带宽: 如果我们的应用程序需要使用网络来与客户端交互,那么我们需要确保服务器拥有足够的网络带宽来支持高访问量。

存储: 如果我们需要大量的数据存储,我们需要确保服务器有足够的存储空间来存储这些数据。

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

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

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

举个工作中实际的例子

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

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

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

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