Liburing Benchmarks#

Summary: req/s, median, best first#

Every run, req/s#

115 runs, no failed request, no run longer than 5.04 s. The runs in each set spread 4-14%: round 5 (and round 4 for a few) came out ~9% lower on every server, C included, so the dip is the machine, not a server; the median of 5 is unaffected. The kernel's conntrack table (net.netfilter.nf_conntrack_max, 262,144 again after a reboot) fills up if runs go back to back: each run opens ~30,000 connections and a closed one stays in the table for 120 s. A full table drops new connections, loopback included, so connect waits for its retries (1, 3, 7, ... s) and the server sits idle (11 of 145 runs in an earlier set). The runner waited while the table held more than 200,000 entries (peak 212,556).

Server CPU per request#

Server CPU time (user + kernel, from /proc/PID/stat) over each 5 s run, the runs above.

No server uses its whole core: req/s is limited by the round trip (64 connections, one request in flight each), so CPU per request is the better measure. Per request on 3.15: get_sqe 1.49 µs, Sqe(ring) 1.36, Sqe(no) 1.25, epoll 1.25. Sqe(ring) saves 0.12-0.16 µs/req over get_sqe, and templates another 0.10-0.16. With templates Liburing ties select.epoll on 3.15 (1.25 vs 1.25) and is 0.01 ahead on 3.14 (1.30 vs 1.31); free-threaded it is 0.02 behind (1.30 vs 1.28 on 3.15t, 1.33 vs 1.31 on 3.14t). Without templates it is ~0.08-0.11 µs/req behind with the GIL and ~0.16-0.18 free-threaded (Sqe(ring)). In C, io_uring costs ~11% less than epoll (0.85 vs 0.95 µs).

Where the Python cost goes#

• Per request, epoll makes ~2 Python calls (recv_into, send) plus one (fd, events) tuple from poll(): 2 cheap syscalls.
• Liburing arms each request with 3 calls (get_sqe), 2 (Sqe(ring)) or 1 (Sqe(no)), then reads cqe[i], .user_data, .res, twice per request (recv + send). Each call costs ~15-25 ns, and an object costs more.
• asyncio is ~3.2-3.6x slower than Liburing, mostly from its own machinery (a task per connection, a future per sock_recv / sock_sendall, a new bytes per recv), not from epoll.
• Left to try: --at (cqe.user_data_at(i) / res_at(i), no CQE objects: ~0.01-0.05 µs/req), multishot recv with a provided buffer ring (one SQE for many recvs), and the free-threaded extra cost.

Summary: req/s with 4 threads, median, best first#

Scaling: req/s by server threads, median#

Server CPU per request, µs, median#

Every run, req/s#

120 runs, no failed request. The server threads are only ~50% busy at any thread count (about 250k req/s each): the load generator, a blocking thread per connection on another CCD, sets the pace, so req/s here shows how the servers scale, and CPU per request what each request costs them.

• With the GIL Liburing scales and epoll does not: 4 threads give Liburing 1.06M req/s (4.0x one thread), epoll 685k (2.5x). A Liburing thread does its kernel work (the sends and receives) inside io_uring_submit_and_wait, with the GIL released, once per batch of completions; an epoll thread releases and retakes the GIL around every recv_into and send, and the threads queue for it: epoll's CPU per request rises from 2.09 µs (one thread) to 3.39 (four), Liburing's stays at ~2.
• Free-threaded both scale (4.4x), and epoll is ~2% ahead (1.15M vs 1.13M req/s on 3.15t; 1.97 vs 2.03 µs per request): the free-threaded extra cost of the single-threaded Liburing server, not a threading one.
• One thread: Liburing and epoll within ~3% of each other on every Python, as in the single-threaded results (this load is lighter per server thread, so the numbers differ from those).