ClickHouse是用于分析的OLAP数据库，因此典型的使用场景是处理相对较少的请求 — 从每小时几个到每秒几十甚至几百个不等 — 但会影响到大量数据（几GB/数百万行）。
但是在其他情况下，它的表现如何？让我们尝试用大量小请求来测试ClickHouse如何处理。这将帮助我们更好地了解可能的使用场景范围和限制。
本文分为两个部分：
- 连接基准测试和测试设置
- 涉及实际数据的最大QPS的场景
环境
对于初始测试，我选择了一台旧工作站：
- 4核 Intel® Core™ 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以及一些输出格式。在这种情况下调整它们的影响大多是可以忽略的。
多线程的影响
默认情况下，ClickHouse使用多个线程处理更大的查询，以有效利用所有CPU核心。
然而，如果您有大量并发连接，多线程将会增加上下文切换、重新加入线程和工作同步方面的额外成本。
为了衡量并发连接与多线程之间的相互作用，让我们来看一下使用默认多线程设置和max_threads=1设置进行的合成选择，以找到最大的100K个随机数的差异。
结论非常简单：在高并发场景中实现更高的QPS，使用max_threads=1设置。
未完待续…
本文涵盖了对ClickHouse的一般连接性测试。我们检查了服务器本身的速度有多快，它可以处理多少简单查询以及哪些设置会影响高并发场景下的QPS。请查看后续文章，我们将深入估算在键值场景中实际查询的最大QPS，这将为测试案例添加数据。
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
负责：
- 中央/分销预订系统性能优化
- 活动&优惠券等营销中台建设
- 交易平台及数据中台等架构和开发设计
目前主攻降低软件复杂性设计、构建高可用系统方向。
参考：