Rust 世界中主流的异步运行时性能测试 Tokio/Tokio-uring/MonoIO/GlommIO

太长不看

  1. 在 ping-pong 场景下,Tokio-uring、MonoIO 和 GlommIO(基于 thread-per-core 和 io-uring 模型)并未表现出比 Tokio 显著更强的性能。
  2. Tokio 展现了强大的生态能力,具有高度的稳定性、丰富的文档、健壮的语法以及出色的可读性。
  3. MonoIO 展现了相当的潜力,但其当前的生态支持还不足以与 Tokio 媲美。此外,在使用类似 poll-io 的兼容方法时,会有明显的性能损失。
  4. GlommIO 的性能是各方面中最差的🤣。

 

性能基准测试摘要

测试所用的机器配置

复制代码
GCP-4core
OS: 22.04.5 LTS (Jammy Jellyfish)
kernel: Linux 5.15.0-1065-gke 
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          46 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   4
  On-line CPU(s) list:    0-3
  Vendor ID:                GenuineIntel
  Model name:             Intel(R) Xeon(R) CPU @ 2.20GHz
复制代码

我使用了 k6 测试框架,在三台不同的 8 核机器上向测试机发送数据。

为了突出 tokio-uring 和 tokio 之间的差异,我特意测试了它们在不同连接数下的性能表现。更多的连接数会导致更高的延迟,同时处理能力呈线性下降。
然而,在这种场景下,我并没有观察到 io-uring 相较于 epoll 或 thread-per-core 模型具有显著的性能优势。

这是在 80 个 connections 下的性能表现。为什么是 80 个 connetions。主要是因为我使用的三台发送流量的机器只有 8个核心,每台大概到达30个 connetions 的时候就已经可以吃满所有 cpu 了。虽然 connections 可以继续往上加,但是代价

是延迟会显著增加。

除了图,我把详细数据也贴在这里给大家参考。

复制代码
Tokio:
rps: 110883/s
vu: 80
latency => 568µs => 0.568ms
cpu usage: 2.72c
rps/c/s: 40766

rps: 109144/s
vu: 420
latency => 4.3ms
cpu usage: 2.80c
rps/c/s: 38980

rps: 97015/s
vu: 2020
latency => 17.01ms
cpu usage: 2.7c
rps/c/s: 35931


Tokio
-uring rps: 113718/s vu: 80 latency => 550.33µs => 0.550ms cpu usage: 3.38c rps/c/s = 33644 rps: 112430/s vu: 420 latency => 4200µs => 4.2ms cpu usage: 3.47c rps/c/s = 32401 rps: 103663/s vu: 2020 latency => 1668.33µs => 16ms cpu usage: 3.35c rps/c/s = 30944

GlommIO rps:
108493/s vu: 80 latency => 553µs => 0.553ms cpu usage: 3.79c rps/c/s: 28626

MonoIO rps:
113239/s vu: 80 latency => 552µs => 0.552ms cpu usage: 2.62c rps/c/s: 43221/c/s
复制代码

 

除了测试上面几个纯 rt 的场景外,我还引入了使用 http lib 或者 web framework 的情况这里同样有一些数据给大家参考

 

复制代码
Tokio-with-hyper
rps: 108694/s
vu: 80
latency => 553µs => 0.553ms
cpu usage: 3.48c
rps/c/s: 31234


GlommIO-with-hyper
rps: 94816/s
vu: 80
latency => 665µs => 0.665ms
cpu usage: 3.85c
rps/c/s: 24628


MonoIO-with-hyper
rps: 109298/s
vu: 80
latency => 576µs => 0.576ms
cpu usage: 3.66c
rps/c/s: 29863


Actix-web
rps: 109976/s
vu: 80
latency => 571µs => 0.571ms
cpu usage: 3.70c
rps/c/s: 29723
复制代码

顺便提一下,也许你在寻找 tokio-uring 和某个 HTTP 库的比较。没错,这里确实没有包含。自从 tokio-uring 被拆分出来后,它的活跃度非常低。官方仓库已经有超过 5 个月没有任何代码合并到主分支,其生态也处于一个很糟糕的状态。

由于社区缺乏活跃性,自从 tokio-uring 于 2021 年发布以来,我尚未找到任何实际使用它的支持 HTTP 库或框架。

我个人正在尝试让它兼容 hyper,但在读取数据时仍遇到一些调度错误,正在努力解决中,因此尚未将其包含在测试中。

如果你知道有任何支持 tokio-uring 的 HTTP 库或框架,请告诉我。我会非常感激,并在测试后将其添加到基准测试中。

 

Reference:

https://www.alibabacloud.com/blog/io-uring-vs--epoll-which-is-better-in-network-programming_599544

 

 

posted @   piperck  阅读(61)  评论(0编辑  收藏  举报
点击右上角即可分享
微信分享提示