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，因为跳过了为每个请求建立连接的额外成本。
现在我们对最大理论可能吞吐量有了感觉，以及ClickHo服务器托管网use 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，这将为测试案例添加数据。
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
负责：
- 中央/分销预订系统性能优化
- 活动&优惠券等营销中台建设
- 交易平台及数据中台等架构和开发设计
目前主攻降低软件复杂性设计、构建高可用系统方向。
参考：
- 编程严选网
本文由博客一文多发平台 OpenWrite 发布！
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
