< 返回版块

性能测试分析

vnt-dev 发表于 2025-06-19 11:52

有没有大佬来分析下这个测试结果 压测项目地址

# Mode Offload Channel Gbps Retr CPU Avg CPU Max Mem Avg Mem Max
1 Async ❌ ❌ 10.6 10480 99.87 150.00 3.16 3.16
2 Async ❌ ✅ 13.3 4781 148.46 223.00 14.89 17.84
3 Async ✅ ❌ 18.4 0 60.21 88.90 20.86 20.86
4 Async ✅ ✅ 15.8 0 107.48 162.00 292.91 351.31
5 Sync ❌ ❌ 13.8 15493 87.10 131.00 1.00 1.00
6 Sync ❌ ✅ 17.2 6439 160.52 241.00 4.81 5.74
7 Sync ✅ ❌ 20.0 0 70.21 105.00 21.05 21.05
8 Sync ✅ ✅ 21.8 0 124.83 188.00 121.68 136.09
9* Sync ✅ ❌ 51.7 2609 152.49 229.00 36.97 36.97
10* Sync ✅ ❌ 17.8 0 54.35 82.40 20.62 20.62

* Test 9: 使用两个线程并发读，两个线程并发写，这种情况吞吐量最高

* Test 10: 使用io-uring

  • Channel: Channel buffering
  • Gbps: Bitrate
  • Retr: Retransmissions
  • CPU Avg/Max: usage in %
  • Mem Avg/Max: usage in MB

问题1：为何用io-uring反而比同步的read更慢了，从实现来看，io-uring系统调用应该更少的？

评论区

写评论
Nayaka 2025-06-19 17:57

https://radiki.dev/posts/compare-sync-uring/

这个是否能解惑?

作者 vnt-dev 2025-06-19 16:10

是一个线程用一个独立的ioUring

--
👇
xiaoyaou: 看过一个类似的说多线程下io_uring比epoll慢的，他那里的原因就是多线程下io_uring共享了同一个io_context，会产生锁竞争并发不起来，解决办法就是每个线程建一个来消除锁。感觉你这个可能也有关系

xiaoyaou 2025-06-19 15:43

看过一个类似的说多线程下io_uring比epoll慢的，他那里的原因就是多线程下io_uring共享了同一个io_context，会产生锁竞争并发不起来，解决办法就是每个线程建一个来消除锁。感觉你这个可能也有关系

1 共 3 条评论, 1 页