Benchmark
The engine is benchmarked head-to-head against nginx serving THIS site’s landing page as a static file — same bytes, same hardware, one server at a time.
Setup
| what | value |
|---|---|
| hardware | AMD EPYC 9554, 7 physical cores / 14 SMT threads |
| server under test | pinned to 4 physical cores / 8 SMT threads (taskset); nginx got matching worker_processes |
| load | wrk on the other 3 physical cores — it never steals CPU from the server it measures; 6 threads, 500 connections, 3-minute runs |
| fairness | logging off on every server; identical bytes served by all |
Round 1 — plain HTML, identical bytes
| server | req/s | p50 |
|---|---|---|
| CMSnap (dynamic page: SQLite + Handlebars, forms, admin, API on board) | 334,707 | 0.71 ms |
| nginx, stock config (static file) | 260,354 | 1.84 ms |
| nginx, hand-tuned: open_file_cache, reuseport, worker affinity, multi_accept | 331,725 | 0.73 ms |
It took a hand-tuned nginx to catch up with a CMS rendering dynamic pages — a statistical tie.
Round 2 — compressed responses, each server’s best
| server | req/s |
|---|---|
| nginx (gzip, precompressed file) | 392,851 |
| CMSnap (zstd, straight from the RAM cache) | 383,284 |
nginx edges ahead only because its gzip file is smaller than the zstd-3 payload (3.36 KB vs 3.58 KB per response) — byte-for-byte it is parity, and zstd decompresses faster in the browser.
Why a CMS can tie a file server
Hot pages are rendered once, compressed once and kept in RAM — the “CMS layer” costs nothing at request time. Totals come from in-memory counters, error pages are prerendered, view SQL is precompiled. Under overload throughput stays flat and latency grows only with the queue — no timeouts, no dropped keep-alives.