编译你的软件
几周前，我举办了一个关于 Kubernetes/Docker 的会议（法语，抱歉，但幻灯片在这里），我在声明中声明，有些人理所当然地让我负责：Docker 镜像很慢，因为它们正在使用旧技术！但是Loïc，这个尺度到底是什么？你本该是个科学家，却给了我们这个便便？我是说，如果你自己编译你的软件（在容器内或不在容器内），你将会有很大的改进。但是人们不相信我。所以为了证明他们是错的，因为我的自我真的很痛苦，我决定根据Redis的编译尝试一个合适的测试场景。 Redis 是最常用的对性能有巨大影响的软件之一。它在行业中被广泛使用，主要用作缓存或快速 KV 内存存储。您可以清楚地想象这种系统的性能影响。所以我们做了我们通常做的事情（以及很多人应该做的事情），我们查看了文档。我们发现了什么？ redis 基准。 Redis 包含 redis-benchmark 实用程序，它模拟 N 个客户端同时发送 M 个查询（它类似于 Apache 的 ab 实用程序）执行的运行命令。
我们想要一个可靠且廉价的基础设施来测试我们的系统。像往常一样，我们选择了Scaleway。但是等等，Redis 是单线程的，为什么我们需要 4 个内核？因为 4 个内核被调度为： 我们的 celery 配置为具有 1 的并发性，所以没有在机器上同时运行多个测试。我们的结果服务器是一个较小的服务器，具有最具创新性的数据平台之一：Warp10。 Warp10 允许我们以非常高的速度和低延迟处理数字。任务将通过 celery 调度，底层使用 Kalvad 的 RabbitMQ 集群。我们对使用这项技术的兴趣是：任务的代码可以在这里找到。如您所见，我们正在通过 python 子进程启动 redis-benchmark，要求以 CSV 格式输出，然后我们对其进行解析并将其推送到 Warp10 上。简单的。
-d 1000 是以字节为单位的 SET/GET 值的数据大小（默认为 2），我们认为 1kB 更现实 -p 是要测试的端口，我们做了一些很棒的事情：我们每个端口运行一个 redis（更多细节如下）redis-benchmark -q -n 100000 --csv -d 1000 --threads 2 -p 6379"test","rps","avg_latency_ms","min_latency_ms","p50_latency_ms","p95_latency_ms"," p99_latency_ms","max_latency_ms""PING_INLINE","200000.00","0.157","0.032","0.143","0.271","0.359","0.623""PING_MBULK","0000.00",".819 0.024","0.127","0.239","0.319","0.807""SET","200000.00","0.153","0.032","0.143","0.239","0.279","1"1 GET","199600.80","0.154","0.032","0.151","0.271","0.327","0.599""INCR","200000.00","0.159","0.032","0.032","0.327" "0.255","0.303","0.519""LPUSH","199600.80","0.178","0.040","0.167","0.287","0.327","0.751""RPUSH","2000" “0.169”、“0.040”、“0.159”、“0.239”、“0.319”、“0.559”“LPOP”、“200000.00”、“0.184”、“0.032”、“0.167”、“0.303”、“0.3039” ,"1.079""RPOP","199203.20","0.182","0.040","0.175","0.295","0.359" ,"1.439""SADD","200000.00","0.154","0.032","0.143","0.247","0.303","0.511""HSET","199600.80","0.1302" ,"0.143","0.199","0.279","0.519""SPOP","199600.80","0.144","0.032","0.143","0.239","0.287","1.103" ,"200000.00","0.163","0.032","0.151","0.255","0.303","0.567""ZPOPMIN","200000.00","0.155","0.032","40","70" ","0.287","0.535""LPUSH (需要对 LRANGE 进行基准测试)","199600.80","0.177","0.040","0.167","0.263","0.319","0.615""0first (LRANGE_first) 100 个元素)","30750.31","1.096","0.144","1.071","1.455","1.551","2.895""LRANGE_300（前 300 个元素）","11106.18","1" 0.136"、"1.559"、"2.367"、"2.831"、"5.423""LRANGE_500（前 500 个元素）"、"6663.56"、"1.496"、"0.216"、"1.471"、"2.070" ,"8.639""LRANGE_600 (前 600 个元素)","5125.84","1.773","0.272","1.695","2.615","3.079","10.119""MSET (10 个键)",3333.133 ","0.257","0.056","0.223","0.351","0.407","2.359" 如您所见，我们有 20 个测试，有 7 个指标，这意味着每次测试，我们将产生140 个指标。为了验证我们的概念，我们选择使用多个 Redis 6.2.4 服务器。请注意，编译后的服务器应该通过执行 make 测试来验证 redis 设置，他们做到了我们只是在容器内的 arch 存储库中使用了默认的 redis。 Redis Stock Arch 正在使用：同样的故事，我们只是采用了测试时可用的最新 Redis 版本。它有以下设置：
几个月前我看到一篇文章，其中有人使用 zig 在 ARM 上编译一些 C 代码，我喜欢这个想法，所以我们想在我们的测试中包含这个设置。这是 Kalvad 的历史性构建，但我们使用 mimalloc 项目而不是使用 jemalloc。完整的 gts 可在此处获得，因此您可以将原始结果导入您自己的 Warp10 实例中。首先，Redis 正在大量使用内存，而我们使用相同版本的 jemalloc 的事实正在减少影响。其次是CPU。 AMD EPYC 7281 于 2017 年第四季度发布，这是旧的。它没有可以进行更多改进的完整指令集。 zig 的味道在这里是一个笑话，但事实证明这是一个很好的笑话：Zig 编译 Redis 比股票 arch 慢 0.288%！齐格干得好！无论您使用何种打包技术，当您开始使用 4 年历史的库和为整个地球编译的软件时，您都会得到这样的结果：慢 142.92%。惊喜：我们之前的测试显示出更好的改进，所以这个结果让我们有点失望。
简单的。出于同样的原因，优化风格并没有太大不同：CPU。我们使用 AMD EPYC 7282（于 2019 年第四季度发布）进行了一些测试，我们看到了更大的改进。这是我们在 Kalvad 应用的规则，我们知道有些我们非常尊重的人也在做同样的事情（你好 CleverCloud）。它将帮助您理解它，使您的应用程序更快、更安全（例如，通过删除 NGiNX 的邮件网关），并将向您展示哪些软件易于维护和可靠。如果您遇到问题而没有其他人可以提供帮助。也许您可以聘请 Kalvad-Team。
