性能比拼: Elixir vs Go(第二轮)
本内容是对知名性能评测博主 Anton Putra Elixir vs Go (Golang) Performance Benchmark (Round 2) 内容的翻译与整理, 有得当删减, 相关指标和结论以原作为准这是第二轮关于 Elixir 和 Go 的对比测试。我收到了一份来自 Elixir 创作者的 Pull Request ，并且我以为有必要分享他所做的一些改进。他还表示，在 Kubernetes 情况下比较这两种语言是没问题的，我只需要为应用程序分配整个 VM（虚拟机）。因此，我使用了 Tolerations（容忍度）和 Affinity（亲和性）来实现这一点。
第一轮测试
在第一轮测试中，我们的目标是返回硬编码的对象给客户端，并测量 P90（90% 分位数）的延迟。同时，我们还会通过每秒哀求数（Requests per Second，简称 RPS）的指标来权衡吞吐量，并记录以下关键数据：
[*]CPU 使用率
[*]内存使用率
[*]可用性（错误率）
[*]CPU 限流（Throttling）
由于我们会将这两个应用程序部署到 AWS 上的生产级 Kubernetes 集群，因此这些指标至关重要。这次 Pull Request 带来了一些改进，我发起你也可以与之前的基准测试进行对比。
第二轮测试
第二轮测试模拟了一个更靠近实际应用场景的案例：
[*]当应用程序吸收到 POST 哀求时，它会剖析哀求体，并将记录插入到关系型数据库中，然后返回数据库生成的 ID 给客户端。
[*]除了前述的性能指标，我们还会额外测量：
[*]数据库操作的延迟（通过内部监测每个应用程序）
[*]数据库的 CPU 使用率（使用 Node Exporter 进行监测）
[*]应用程序创建的数据库毗连池巨细（使用 Postgres Prometheus Exporter 监测）
所有的基准测试都在 AWS 上运行。在本次测试中，我使用了一台 存储优化型 Graviton2 xlarge 实例 作为数据库服务器。不过，我以为未来大概需要升级它。此外，我还创建了一个 EKS 集群，其中：
[*]盘算优化型节点 用于 Prometheus、Grafana 和 客户端 生成负载。
[*]M7A Large 实例 用于运行应用程序，每个应用程序都部署在自己的 EC2 实例上。
AWS 并未自制，为了支持我的频道，我提供 一对一咨询服务。如果你感兴趣，可以在视频描述中找到更多信息。
开始执行第一轮测试
整个测试连续 1.5 小时，但我会将其压缩到 1.5 分钟 的展示时间。此外，你可以在此处找到 完整的源代码。
第一轮测试效果
1. 每秒哀求数（Requests per Second, RPS）
https://i-blog.csdnimg.cn/img_convert/0d9c645198e4dc274f398ab65f8d77a5.jpeg
[*]Elixir 处理了 20,000 RPS，比之前的基准测试提拔了 2,000 RPS，可以看到一定的性能提拔。
[*]Go 预期到达了 60,000 RPS，依然领先。
2. 客户端延迟
https://i-blog.csdnimg.cn/img_convert/32232e30f0eb2b047608d9067c8e4bd8.jpeg
[*]Elixir 的延迟相比之前的基准测试略有降低，延迟越低越好。
[*]但它仍然远远落后于 Go 的性能。
3. CPU 使用率
https://i-blog.csdnimg.cn/img_convert/76ec45eb7624a53018a87dd7f2b7cf46.jpeg
[*]CPU 使用率越高，吞吐量越低，延迟越高，这并不不测。
[*]Elixir 在这个测试中表现不如 Go，至少在这个特定的工作负载下。
4. 可用性（错误率）
https://i-blog.csdnimg.cn/img_convert/407ce7b8dd3df4c64f1f0b58261abf0a.png
[*]可用性 通过每秒错误数来权衡，错误数越低，代表体系越稳固。
[*]这个图表展示的是每秒错误数，错误数越高，代表可用性降落。
5. 内存使用情况
https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=https%3A%2F%2Ffiles.mdnice.com%2Fuser%2F99174%2F1bbf960b-c35d-4205-8a58-3df512e5a2ed.jpg&pos_id=img-kqgLem20-1745055773677
[*]之前已经预推测，在 Go 瓦解之前，它的内存使用率会不断上升。
6. CPU 限流（CPU Throttling）
https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=https%3A%2F%2Ffiles.mdnice.com%2Fuser%2F99174%2F9dda5af5-d067-4f77-b938-dc99e82feedd.jpg&pos_id=img-8WwaCVmz-1745055773677
[*]Elixir 的 CPU Throttling 现象更严重，由于它更早到达 CPU 使用率的上限，相比之下 Go 应用程序的 CPU 资源管理更高效。
这一轮静态测试的效果可以作为后续测试的基准。
开始执行第二轮测试
这轮测试的展示时间同样压缩到了 1.5 分钟。
第二轮测试效果
1. 每秒哀求数（Requests per Second, RPS）
https://i-blog.csdnimg.cn/img_convert/0f0fad4bf037e1590e73f9539646a18c.png
[*]这次测试中，相较于之前的基准测试，并没有明显的提拔，甚至可以说有轻微的降落。
[*]Go 在两次测试中都稳固在 22,000 RPS。
2. POST 哀求延迟
https://i-blog.csdnimg.cn/img_convert/b7ff33640c1ac04d805c4de69a613110.png
[*]Elixir 的延迟相比之前的测试有所降低，表现略有提拔，但仍然不及 Go。
3. 数据库插入延迟
https://i-blog.csdnimg.cn/img_convert/844219349542892265260e11034ebd92.png
[*]大部分哀求的延迟都来自数据库操作，这在预期之内。
[*]我按照发起创建了 4 个数据库毗连池，每个池有 125 个毗连。
4. CPU 使用率
https://i-blog.csdnimg.cn/img_convert/1bff35dfd7e799ccffb033be23273c69.jpeg
[*]这里没有太多不测的发现。
[*]未来我大概需要增加数据库毗连池的巨细，以便让 CPU 资源利用率到达更高水平。
[*]数据库毗连池巨细 和 网络 I/O 通常是瓶颈，毗连数越多，吞吐量越大。但同时，也需要监控数据库本身的康健状况，确保它不会成为新的瓶颈。
5. 可用性
https://i-blog.csdnimg.cn/img_convert/bc5b711ec60efe98e1bf0043c34e8d07.png
[*]这次测试中，我将超时时间增加到 5 秒，因此没有看到错误。
6. PostgreSQL 数据库的 CPU 使用
https://i-blog.csdnimg.cn/img_convert/3ea3a5732f177cdc56645537d350964f.png
[*]上一次测试 使用的是 AMD 处理器，这次测试采用的是 Graviton4 第四代处理器。
7. 数据库毗连池巨细
https://i-blog.csdnimg.cn/img_convert/48fa10815f5f0735eaf29c2850c602c2.png
[*]Elixir 应用在启动时会立刻创建 500 个数据库毗连。
[*]Go 则会根据负载逐步增加毗连数。
[*]我以为未来大概需要将毗连数增加至 1,000，以进一步优化性能。
[*]值得一提的是，Amazon RDS 默认的最大毗连数是 5,000，以是应该不会有太大问题。
8. 内存使用情况
https://i-blog.csdnimg.cn/img_convert/0f6b426f13b85814544a4746d0df38e8.png
[*]如果你有更好的优化方案，欢迎提交 Pull Request！
[*]我总是乐意承认自己的错误，并在合理的情况下重新运行测试。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]