ngx_mzstd NGINX Module Brings Zstd Compression to Thread Pools

On-the-fly compression in NGINX traditionally suffers from event loop blocking when processing large payloads. Standard modules like tokers/zstd-nginx-module handle all compression work directly inside the single-threaded event loop, forcing small concurrent requests to wait while heavy assets—such as a 1.03 MB JavaScript bundle compressed at level 19—consume roughly 200 milliseconds of processing time per file.

To overcome this bottleneck, ngx_mzstd has been developed in Rust built on top of the mzstd encoder. It serves as a drop-in replacement for tokers/zstd-nginx-module using identical directives and requiring no libzstd. Its primary advantage is leveraging NGINX thread pools for compression, ensuring that compressing large responses does not halt worker connections from serving other traffic.

Benchmark numbers gathered under WSL2 on October 20, 2026, demonstrate a dramatic performance shift. When eight large requests arrived simultaneously at compression level 19, tokers/zstd-nginx-module caused small request p99 latency to spike to 1.5 seconds, whereas ngx_mzstd running on a 4-thread pool maintained latency at an impressive 1.7 to 2.0 milliseconds.

Stock photo for illustration only, not from the actual event

Regarding segmentation, ngx_mzstd splits responses into default 1 MiB chunks (zstd_parallel_segment_size), processing up to 4 segments simultaneously across pool threads (zstd_parallel_tasks). Although segments are not fully independent—requiring context boundaries to maintain high compression ratios comparable to event loop execution—the trade-off delivers substantial tail latency improvements.

Source: Dev.to