Brotli on Nginx thread pools: ngx_mbrotli vs. ngx_brotli

A comparison of two on-the-fly Brotli modules for NGINX shows that moving compression off the worker event loop into thread pools eliminates large tail latency for other connections. google/ngx_brotli and NGINX’s stock gzip compress inside the worker thread, so compressing a 1 MB bundle at Brotli level 6 or level 11 can consume ~16 ms to ~1.2 s of CPU, blocking all other requests on that worker; measured p99 latency for small uncompressed requests rose from 1.9 ms to 17-514 ms. ngx_mbrotli (a Rust wrapper around mbrotli) adds brotli_thread_pool support: responses are split into 1 MiB segments, each compressed as a thread task (up to 4 tasks by default) and completed handlers hand bytes back to the event loop. In tests on NGINX 1.30.6 (one worker on an i7-13700KF under WSL2, SHA-256-verified outputs) ngx_mbrotli with a 4-thread pool kept small-request p99 at 1.7-3.3 ms, essentially the same as no compression.

Putting compression on a pool also raises throughput: one worker with a 4-thread pool served 3.8-15× as many Brotli responses per second on 85 KB-2.2 MB files versus google/ngx_brotli, with the biggest gains at levels 9 and 11. Some of the speedup is parallel CPU use (~4×), and some comes from the mbrotli encoder (the C encoder used by google/ngx_brotli allocates a 32 MiB hash at level 9, hurting small-file performance). The trade-offs are memory and slight compression ratio loss: under 8 concurrent large responses a worker peaked at 138-995 MiB (11-26× higher than google/ngx_brotli), and responses spanning multiple 1 MiB segments were 0.9-5.2% larger.