|
| 1 | +# turbopg / pg.zig — blocking vs io_uring transport A/B |
| 2 | + |
| 3 | +> **Scope:** the only code path that differs between the two builds is |
| 4 | +> the `Stream` struct in `zig/pg/src/stream.zig`. Everything else |
| 5 | +> (wire-protocol codec, `Conn`, `Pool`, result decoding) is identical. |
| 6 | +> The io_uring path is **one ring per connection**, single in-flight |
| 7 | +> SQE per `read` / `writeAll` (submit + `copy_cqe`). **No scheduler, no |
| 8 | +> SQPOLL, no multi-shot, no registered fds.** The real async win |
| 9 | +> needs all of those on top. Per `AGENTS.md`, do not cite these |
| 10 | +> numbers in release notes, framework comparison tables, or |
| 11 | +> marketing copy. |
| 12 | +
|
| 13 | +## Environment |
| 14 | + |
| 15 | +- Apple `container` CLI (two Linux microVMs on macOS, shared vnic) |
| 16 | +- DB container: `postgres:18`, trust auth, default shm, `192.168.64.14` |
| 17 | +- Bench container: `debian:bookworm-slim` + Zig 0.16.0 aarch64-linux |
| 18 | +- Kernel (both VMs): `Linux 6.18.5 aarch64` |
| 19 | +- pg.zig build: `-Doptimize=ReleaseFast` |
| 20 | +- Workload: N worker threads, each owns one `pg.Conn`, hot loop of a |
| 21 | + single query shape for the duration |
| 22 | +- Network: container-to-container via the default `container` network |
| 23 | + |
| 24 | +## Variants |
| 25 | + |
| 26 | +| label | build flag | transport used | |
| 27 | +|------------|--------------------|--------------------------| |
| 28 | +| `blocking` | `-Diouring=false` | `PlainStream` (read / send via libc syscalls) | |
| 29 | +| `iouring` | `-Diouring=true` | `IoUringStream` (one ring per conn, `IORING_OP_SEND` / `IORING_OP_RECV`, submit + `copy_cqe`) | |
| 30 | + |
| 31 | +Both variants share the same connect path, auth path, and `Reader`. |
| 32 | + |
| 33 | +## Workloads |
| 34 | + |
| 35 | +| id | SQL | notes | |
| 36 | +|----|----------------------------------------------|-------| |
| 37 | +| 1 | `SELECT 1` | smallest round trip | |
| 38 | +| 2 | `SELECT id FROM generate_series(1, 50) AS id` | 50 rows back per query, ~300 B response | |
| 39 | + |
| 40 | +## Results |
| 41 | + |
| 42 | +4 worker threads, 10 s per run. |
| 43 | + |
| 44 | +### query=1 (`SELECT 1`), median of 3 |
| 45 | + |
| 46 | +| variant | median rps | min | max | |
| 47 | +|----------|-----------:|--------:|--------:| |
| 48 | +| blocking | 14,967.12 | 14,878 | 15,140 | |
| 49 | +| iouring | 15,178.03 | 15,127 | 15,230 | |
| 50 | + |
| 51 | +Δ: **+1.4 %**, well within run-to-run noise with n=3. |
| 52 | + |
| 53 | +### query=2 (`SELECT` generate_series(1,50)), median of 5 |
| 54 | + |
| 55 | +| variant | median rps | min | max | |
| 56 | +|----------|-----------:|--------:|--------:| |
| 57 | +| blocking | 13,903.37 | 13,770 | 14,001 | |
| 58 | +| iouring | 13,849.02 | 13,752 | 13,929 | |
| 59 | + |
| 60 | +Δ: **−0.4 %**, again within noise. |
| 61 | + |
| 62 | +## What this tells us |
| 63 | + |
| 64 | +1. Per-connection single-SQE io_uring is **roughly a wash** on a |
| 65 | + driver that was already blocking-sync. Expected: we trade one |
| 66 | + `recv()` syscall for one `io_uring_enter(submit)` + |
| 67 | + `io_uring_enter(wait_cqe)`, so the per-op syscall cost is |
| 68 | + approximately even. Kernel fastpath for small receives on a local |
| 69 | + TCP loop is already very fast. |
| 70 | +2. On q=2 (bigger response, more bytes per recv) io_uring trends |
| 71 | + slightly slower — consistent with the extra ring bookkeeping |
| 72 | + overhead showing up once the per-op cost matters at all. |
| 73 | +3. No regressions, no query errors. The abstraction and the ring |
| 74 | + plumbing work correctly for the full `Conn` lifetime (connect, |
| 75 | + startup, simple query, extended query, close). |
| 76 | + |
| 77 | +## What would actually move the needle |
| 78 | + |
| 79 | +The next items (deliberately **not** in this PR): |
| 80 | + |
| 81 | +- **SQPOLL** so submitting no longer needs an `io_uring_enter` |
| 82 | + syscall in the common case. |
| 83 | +- **Batched send**: queue up the parse/bind/describe/execute/sync |
| 84 | + packets into one `IORING_OP_SEND` instead of the current per-packet |
| 85 | + writes. |
| 86 | +- **A cooperative scheduler** so one ring drives N connections |
| 87 | + concurrently and a waiting query yields the thread rather than |
| 88 | + blocking on `copy_cqe`. This is the real win and turns this from a |
| 89 | + neutral change into an actual throughput improvement. |
| 90 | + |
| 91 | +## Caveats (read these) |
| 92 | + |
| 93 | +- 3–5 iterations, 10 s each, one client, one DB. Enough to catch |
| 94 | + big regressions, not enough to publish percentage claims. |
| 95 | +- `postgres:18` with default config, no tuning, `trust` auth. |
| 96 | +- Apple `container` runs each container in its own microVM; cross-VM |
| 97 | + network adds a real-ish TCP path but results will not match a |
| 98 | + co-located production setup. |
| 99 | +- No TLS. The io_uring path is plaintext-only in this PR; |
| 100 | + `-Dopenssl_lib_name=...` still picks TLS + the old blocking socket. |
| 101 | + |
| 102 | +## Reproducing |
| 103 | + |
| 104 | +```bash |
| 105 | +# 1. Start Postgres 18 |
| 106 | +container run -d --name pg18 -e POSTGRES_HOST_AUTH_METHOD=trust postgres:18 |
| 107 | + |
| 108 | +# 2. Build the bench image once |
| 109 | +container build -t turbopg-bench \ |
| 110 | + -f bench/turbopg/Containerfile bench/turbopg |
| 111 | + |
| 112 | +# 3. Find the pg18 IP (field ADDR in `container ls`) |
| 113 | +PG_IP=$(container ls | awk '$1=="pg18" {print $6}' | cut -d/ -f1) |
| 114 | + |
| 115 | +# 4. Run |
| 116 | +container run --rm -m 4G -c 4 \ |
| 117 | + -e PGHOST="$PG_IP" \ |
| 118 | + -e BENCH_QUERY=1 \ |
| 119 | + -e BENCH_ITERS=5 \ |
| 120 | + -v "$PWD":/work \ |
| 121 | + turbopg-bench |
| 122 | +``` |
| 123 | + |
| 124 | +Override `BENCH_QUERY` (1 or 2), `BENCH_THREADS`, `BENCH_DURATION`, |
| 125 | +`BENCH_ITERS` as needed. |
0 commit comments