ClickHouse最大QPS到底咋估算？-编程知识

ClickHouse是用于分析的OLAP数据库，因此典型的使用场景是处理相对较少的请求 — 从每小时几个到每秒几十甚至几百个不等 — 但会影响到大量数据（几GB/数百万行）。

但是在其他情况下，它的表现如何？让我们尝试用大量小请求来测试ClickHouse如何处理。这将帮助我们更好地了解可能的使用场景范围和限制。

本文分为两个部分：

连接基准测试和测试设置
涉及实际数据的最大QPS的场景

环境

对于初始测试，我选择了一台旧工作站：

4核 Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
8GB RAM
SSD硬盘
CentOS 7

本文中呈现的结果是从该计算机收集的，但当然，很有趣的是在更强大的硬件上重复这些测试。我把这项任务交给我们的读者，这样你就可以在自己的硬件上测试ClickHouse在不同场景下的最大QPS。如果你这样做了，请分享你的结果！为了运行基准测试，我还创建了一组脚本，可以在Altinity的GitHub上免费获取：https://github.com/Altinity/clickhouse-sts/。这些脚本需要Docker（我使用的是v18.09）和Bash。要运行测试套件，只需克隆GitHub存储库，并在根文件夹中运行‘make test’命令。它会在你的主机上执行所有测试（需要几个小时），并将结果放入一个CSV文件中，稍后可以在Excel、Pandas或ClickHouse本身中进行分析。当然，你也可以分享你的发现，以便与本文中的结果进行比较。

这些脚本使用了以下工具：

https://github.com/wg/wrk，一个轻量级且快速的HTTP基准测试工具，允许创建不同的HTTP工作负载
ClickHouse发行版中包含的clickhouse-benchmark工具，用于本地协议ClickHouse测试

这两个工具都允许你创建所需并发量的负载（模拟不同数量的并发客户端），并测量每秒处理的查询数和延迟百分位数。

关于ClickHouse处理并发请求的几点说明

默认情况下，ClickHouse可以处理高达4096个入站连接（max_connections在服务器配置文件中设置），但只会同时执行100个查询（max_concurrent_queries），因此所有其他客户端将在队列中等待。客户端请求可以保持在队列中的最长时间由queue_max_wait_ms设置定义（默认为5000或5秒）。这是一个用户/配置文件设置，因此用户可以定义较小的值，在队列过长的情况下提示异常。http连接的长连接超时默认相对较短 — 3秒（keep_alive_timeout设置）。

还有许多高级网络相关设置，用于微调不同的超时、轮询间隔、监听回溯大小等设置。

HTTP ping：HTTP服务器的理论最大吞吐量

首先，让我们检查ClickHouse自身使用的HTTP服务器有多快。换句话说，服务器可以处理多少个“无所事事”的请求。

对于HTTP，两种主要情况很重要：

使用保持连接（保持持久连接进行多个请求，而无需重新连接）
不使用保持连接（每个请求都建立新连接）

此外，默认情况下ClickHouse的日志级别非常详细（‘trace’）。对于每个查询，它会向日志文件写入几行，这对于调试很好，但当然会增加一些额外的延迟。因此，我们还要检查禁用日志的相同2种场景。

我们对不同并发级别进行了测试，以模拟不同数量的同时连接的客户端（一个接一个地发送请求）。每个测试执行15秒，然后取每秒处理的平均请求数。

结果：

在X轴上，您可以看到同时连接的客户端数。在Y轴上，我们有每个特定场景中每秒处理的平均请求数。

好吧，结果看起来不错：

在每个场景中，在8到64个并发连接之间，QPS的最大值都在那台机器上。
最大吞吐量约为97K QPS，启用保持连接并禁用日志。
启用日志时，速度要慢大约30%，大约为71K QPS。
两个不使用保持连接的变体要慢得多（约为18.5 kqps），甚至在这里看不出日志开销。这是预期的，因为使用保持连接，ClickHouse肯定可以处理更多的ping，因为跳过了为每个请求建立连接的额外成本。

现在我们对最大理论可能吞吐量有了感觉，以及ClickHouse Web服务器可以实现的并发级别。实际上，ClickHouse的HTTP服务器实现相当快。例如，NGINX在相同的机器上使用默认设置大约可以提供30K每秒。

SELECT 1

让我们再进一步，检查一个微不足道的 ‘SELECT 1’ 请求。这样的查询在查询解析阶段被‘执行’，因此这将展示‘网络 + 授权 + 查询解析器 + 格式化结果’的理论最大吞吐量，即真实请求永远不会更快。

我们将测试使用保持连接和不使用保持连接的http和https选项，以及本地客户端（安全和非安全）。

结果如下：

这些结果与简单的ping相比显示了相当大的降级。我们得到了：

最佳情况下约为14K QPS：http & 保持连接。
https & 保持连接情况稍差（13K QPS）。在这种情况下，https的开销并不显著。
http 不使用保持连接时约为10.7 kqps。
本地客户端（不安全）约为10.1 kqps。
本地客户端（安全）约为9.3 kqps。
无保持连接的https表现相当差，约为4.3 kqps。

在最高并发级别上，我们注册了几十个连接错误（即少于0.01%），这很可能是由于操作系统层面的套接字重用问题引起的。ClickHouse在该测试中表现稳定，我没有注册到任何明显的问题。

本地协议显示的性能比http更差可能会让人惊讶，但实际上这是预期的：本地TCP/IP更加复杂，具有许多额外的协议特性。它不适合高QPS，而是适合传输大块数据。

此外，在本地客户端中，随着并发性增加，QPS会出现相当大的下降，在更高的并发级别（>3000）时系统会变得不响应并返回无结果。这很可能是由于clickhouse-benchmark工具为每个连接使用一个单独的线程，线程数和上下文切换过多导致的。

现在让我们看看延迟，即每个客户端等待答案的时间。这个数字在每个请求中会有所变化，因此图表显示了每种情况下延迟的90th percentile。这意味着90%的用户得到的答案比显示的数字更快。

延迟（90th percentile）– 1-256 并发级别

随着并发性的增长，延迟的恶化是可以预料的。目前看起来非常不错：如果您少于256个并发用户，您可以期望延迟在50毫秒以下。

让我们看看高并发性会如何影响。

延迟（90th percentile）– >256 并发级别

现在延迟的恶化更为显著，而且本地协议再次显示出最差的结果。

有趣的是，不使用保持连接的http请求表现非常稳定，并且即使有2K并发用户，延迟也低于50ms。没有保持连接时，延迟更加可预测，并且标准差在并发性增加时保持较小，但QPS会略有降低。这可能与Web服务器的实现细节有关：例如，当使用每个连接一个线程时，线程上下文切换可能会减慢服务器速度，并在一定并发级别后增加延迟。

我们还检查了其他设置，如max_concurrent_queries、queue_max_wait_ms、max_threads、network_compression_method、enable_http_compression以及一些输出格式。在这种情况下调整它们的影响大多是可以忽略的。