如何预估系统QPS？

写在前面

本文隶属于专栏《100个问题搞定大数据理论体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和文献引用请见100个问题搞定大数据理论体系

解答

1. 使用限流(Throttling)的方式
2. 在系统交付前进行性能测试(Performance Test)
3. 分析系统在实际使用时产生的日志(Log)

补充

使用限流(Throttling)的方式

如果你是使用Java语言进行编程的，就可以使用 Google Guava库中的 RateLimiter 类来定义每秒最多发送多少请求到后台处理。

假设我们在每台服务器都定义了一个每秒最多处理1000个请求的RateLimiter，而我们有N台服务器，在最理想的情况下，我们的QPS可以达到1000*N。

雷区

这个请求数并不是设置得越多越好。

因为每台服务器的内存有限， 过多的请求堆积在服务器中有可能会导致内存溢出(Out-Of-Memory)的异常发生，也就是所有请求所需要占用的内存超过了服务器能提供的内存，从而让整个服务器崩溃。

在系统交付前进行性能测试(Performance Test)

我们可以使用像Apache Jmeter又或是Load Runner这类型的工具对系统进行性能测试。

这类工具可以测试出系统在峰值状态下可以应对的QPS是多少。

雷区

有的开发者可能使用同一类型的请求参数，导致后台服务器在多数情况下命中缓存(Cache Hit)。

这个时候得到的QPS可能并不是真实的QPS打个比方，服务器处理请求的正常流程需要查询后台数据库，得到数据库结果后再返回给用户，这个过程平均需要1秒。
在第一次拿到数据库结果后，这个数据就会被保存在缓存中，而如果后续的请求都使用同一类型的参数，导致结果不需要从数据库得到，而是直接从缓存中得到，这个过程我们假设只需要0.1秒。
那这样，我们所计算出来的QPS就会比正常的高出10倍。所以在生成请求的时候，要格外注意这一点。

分析系统在实际使用时产生的日志(Log)

系统上线使用后，我们可以得到日志文件。一般的日志文件会记录每个时刻产生的请求。

我们可以通过系统每天在最繁忙时刻所接收到的请求数，来计算出系统可以承载的QPS。

雷区

这种方法不ー定可以得到系统可以承载的最大QPS。

在这里打个比喻，一家可以容纳上百桌客人的餐馆刚开业，因为客流量还比较小，在每天最繁忙的时候只接待了10桌客人。

那我们可以说这家餐馆最多只能接待10桌客人吗? 不可以。

同样的，以分析系统日志的方法计算出来的QPS并不一定是服务器能够承载的最大QPS。

想要得到系统能承受的最大QPS，更多的是性能测试和日志分析相结合的手段。