Loading...
Loading...
Benchmarks
Both apps render byte-for-byte identical React trees from identical data, so the numbers reflect the runtime, not the workload. Ossido renders through a multi-threaded V8 pool embedded in a Rust/axum server; Next.js runs on Node.js, scaled across cores with the cluster module.
Throughput
Higher is better. Every app is a production build rendering on every request - neither serves cached HTML. Each scenario runs single-threaded and across all 16 cores.
/ssr60 product cards rendered per request
/heavy5000-row table, CPU-bound render
/api/bench100-item JSON payload (Rust vs Node)
Latency
The 99th-percentile response time under the same load. Lower is better.
| Scenario | Ossido ×1 | Ossido ×16 | Next ×1 | Next ×16 |
|---|---|---|---|---|
| SSR — catalogue | 26 | 14 | 101 | 68 |
| SSR — heavy table | 1,304 | 356 | 11,583 | 674 |
| JSON API | 0.8 | 0.8 | 33 | 238 |
Streaming SSR
The streaming route flushes the shell first, then streams a 3000-row table. A lower TTFB means the browser starts painting sooner. Lower is better.
/streamMemory efficiency
Ossido scales SSR across cores with V8 render threads inside a single Rust process (one shared heap); Next.js forks 16 full Node processes (a heap each). Identical /ssr load at each parallelism level, sampling resident memory throughout.
| Parallelism | Ossido req/s·MB | Next req/s·MB | Ossido RSS (MB) | Next RSS (MB) |
|---|---|---|---|---|
| ×1 (single) | 5.47 | 1.11 | 375 | 516 |
| ×2 | 1.60 | 1.18 | 667 | 956 |
| ×4 | 5.15 | 1.20 | 1,133 | 1,802 |
| ×8 | 4.55 | 1.05 | 2,000 | 3,493 |
| ×16 | 3.12 | 0.65 | 2,928 | 6,148 |
Idle resident memory at ×16: Ossido 107 MB vs Next.js 1,813 MB.
Load generated with autocannon: 50 connections, 10s per scenario after a 3s warm-up. Single-threaded runs Ossido with OSSIDO_SSR_THREADS=1 and Next.js as one Node process; multi-threaded runs Ossido with one V8 render isolate per core and Next.js as a 16-worker cluster. Results are hardware-dependent - regenerate them on your own machine.