Rust 世界中主流的非同步執行時效能測試 Tokio/Tokio-uring/MonoIO/GlommIO

piperck發表於2024-12-10
Rust非同步Mono

太長不看

  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

相關文章