PRNext vs Next.js at 2 CPU · 1 GiB: SSR and heavy rendering
渲染 100 行和渲染 1,000 行讲述不同的故事。在相同的资源限制下,所服务的路由可以改变运行时决策。
阅读结果和权衡 →基准·十月 29, 2026
当 CPU 受到约束时,降低每次响应的成本会有所帮助。在小型服务器上,一些额外的 MiB 也很重要。此案例说明了为什么两个测量结果并列。
Measured: PRNext 0.1.18-alpha candidate, distinct from the final npm archive. Details and hashes below. 测量了哪个代码?
On the 100-row page, the PRNext candidate uses about 37% less CPU per response and delivers 59% more validated requests than Next.js. Its median PSS is around 12% higher. This may suit a CPU-constrained application, but does not demonstrate a RAM saving.
此预算对具有 1 vCPU 和 1.9 GiB 的主机施加 0.7-CPU 配额和 700-MiB 内存限制。生成器共享该物理 CPU。结果描述了这种特定的设置及其争用,而不是市场上的每个小型 VPS。
The streaming route includes a 40-ms Suspense wait. PRNext uses roughly 42% less CPU per response while memory remains higher. That wait is part of the scenario; the route does not represent every streaming application.
1,000-row 页面大大增加了两个运行时的 CPU 成本。 PRNext 在此预算下保留了较小的吞吐量优势,但两个窗口无法确定此差距是稳定的。对于快速 API,在得出结论之前还要检查生成器限制标志。
衡量您的服务器及其依赖项和数据库,然后为爆发预留空间。在 700-MiB 限制下测量的 PSS 并不意味着 700-MiB VPS 就足够了:操作系统、其他服务和实际工作负载也需要内存。在更改运行时间之前验证路由兼容性。
配额 0.7 CPU · 700 MiB · Node 22.23.4 · 1 worker PRNext · 1 Next.js process · old-space 384 MiB
Higher throughput is better; lower latency, CPU and memory are better.
| 公制 | PRNext 候选人 | Next.js 16.4.3 |
|---|---|---|
| 经验证的吞吐量请求数/秒 | 81.33 | 51.00 |
| p95潜伏期ms | 264.25 | 420.90 |
| CPU / 响应CPU 毫秒 | 8.46 | 13.39 |
| PSS内存MiB | 113.88 | 101.38 |
| 公制 | PRNext 候选人 | Next.js 16.4.3 |
|---|---|---|
| 经验证的吞吐量请求数/秒 | 11.33 | 10.33 |
| p95潜伏期ms | 1,550.25 | 1,661.80 |
| CPU / 响应CPU 毫秒 | 58.92 | 62.10 |
| PSS内存MiB | 139.51 | 119.46 |
| 公制 | PRNext 候选人 | Next.js 16.4.3 |
|---|---|---|
| 经验证的吞吐量请求数/秒 | 518.17 | 352.80 |
| p95潜伏期ms | 61.40 | 90.05 |
| CPU / 响应CPU 毫秒 | 1.27 | 1.94 |
| PSS内存MiB | 139.63 | 113.08 |
在这种情况下,负载生成器可能会限制吞吐量。小差距不足以区分运行时间。
| 公制 | PRNext 候选人 | Next.js 16.4.3 |
|---|---|---|
| 经验证的吞吐量请求数/秒 | 138.13 | 80.03 |
| p95潜伏期ms | 182.65 | 307.25 |
| CPU / 响应CPU 毫秒 | 4.98 | 8.62 |
| PSS内存MiB | 135.32 | 115.54 |
The 2026-10-29 campaign uses React 19.3.1, the PRNext Balanced profile and gzip. Each variant gets 5 seconds of warmup, followed by 15 seconds of measurement with 16 connections. Values are medians of two alternating windows per variant, route and budget.
吞吐量指的是成功且经过验证的响应。 CPU 表示每次成功响应需要 CPU 时间。 RAM 是 MiB 中的中值进程树 PSS,而不是 RSS 或总 VPS 内存。报告的延迟是两个窗口 p95 值的中位数,而不是对所有请求重新计算的 p95。
PRNext is a development candidate for 0.1.18-alpha, with a manifest reporting 0.1.17-alpha. Next.js is version 16.4.3. The final 0.1.18-alpha release was not measured by this campaign: these figures do not measure its npm archive.
对合成应用进行两次短时间重复不提供置信区间。小型 VPS 与负载生成器共享其 CPU,而快速 API 路由可能受到生成器限制。主机之间的硬件和节点版本不同,因此跨预算的比较无法隔离硬件影响。
这些测量无法确定并发产品用户、VPS 上适合多少项目或账单节省。数据库、外部调用、缓存、浏览器工作和应用程序唤醒都会改变结果。睡眠和耐力观察仍在全面比较中。
从最繁忙和最昂贵的路线开始。在比较速度之前验证响应内容和错误。保持两个运行时的配额、依赖项、缓存设置和负载相同。在做出决定之前重复更长的时间。