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以及一些输出格式。在这种情况下调解它们的影响大多是可以忽略的。
多线程的影响

默认情况下，ClickHouse利用多个线程处理更大的查询，以有效利用全部CPU核心。
然而，如果您有大量并发连接，多线程将会增加上下文切换、重新参加线程和工作同步方面的额外成本。
为了权衡并发连接与多线程之间的相互作用，让我们来看一下利用默认多线程设置和max_threads=1设置举行的合成选择，以找到最大的100K个随机数的差异。

结论非常简朴：在高并发场景中实现更高的QPS，利用max_threads=1设置。
未完待续…

本文涵盖了对ClickHouse的一样平常连接性测试。我们检查了服务器本身的速度有多快，它可以处理多少简朴查询以及哪些设置会影响高并发场景下的QPS。请查看后续文章，我们将深入估算在键值场景中实际查询的最大QPS，这将为测试案例添加数据。
关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都技术专家兼架构，多家大厂后端一线研发履历，各大技术社区头部专家博主。具有丰富的引领团队履历，深厚业务架构息争决方案的积累。
负责：

• 中央/分销预订系统性能优化
  
• 活动&优惠券等营销中台建设
  
• 交易平台及数据中台等架构和开发设计
  

目前主攻降低软件复杂性设计、构建高可用系统方向。

参考：

• 编程严选网
  

本文由博客一文多发平台 OpenWrite 发布！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。