如何优化Spartacus SSR在高并发负载下的运行性能？

并发承载能力结论 #

Spartacus 原生SSR优化层的concurrency参数仅代表渲染队列的最大排队长度，不代表单进程可稳定承载的实时渲染并发数。基于NgExpressEngine的默认SSR实现运行在单Node.js进程中，Angular渲染过程依赖Domino模拟DOM环境、Zone.js做上下文追踪，CPU开销极高，单进程无缓存场景下可稳定支撑的实时渲染并发仅为2-4。
测试场景中10并发下80%请求回退CSR空壳、2并发下SSR运行正常的表现，是默认实现的固有瓶颈，和自定义代码无关——当并发超过单进程承载阈值时，排队请求的等待时长会快速上涨，很容易触碰timeout阈值直接返回CSR响应，即便手动调高timeout数值，只要队列拥塞问题存在，超时回退就会持续出现。
当前使用的SSR配置如下，其中concurrency参数设置远高于单进程实际承载能力，是加剧队列拥塞的原因之一：

const engineConfig: SsrOptimizationOptions = {
  timeout: 5000, // spartacus default: 3000
  maxRenderTime: 300_000, // spartacus default: 300_000 (5min)
  concurrency: 20, // spartacus default: 20
  cache: false,
  cacheSize: 20,
  debug: false,
};

千级页面场景下高负载SSR回退问题解决方法 #

全量页面缓存不适用于千级以上页面的站点，可通过以下组合方案解决高负载下的异常回退问题：

• 多进程水平扩容拆分流量
  不要用单Node.js进程承载所有SSR流量，使用PM2或容器编排工具启动多个SSR进程，进程数和服务器CPU核心数保持1:1配比（避免多进程抢CPU带来的上下文切换开销），前置负载均衡层将请求均匀分发到各进程，保证单进程承接的实时渲染并发稳定在2-4的安全区间，从根源避免渲染队列拥塞。
• 分层缓存替代全量缓存
  不需要缓存所有页面，用两层缓存覆盖绝大多数流量的同时控制缓存规模：
  • 第一层做高频页面短TTL缓存：将访问量排名前20%的高频页面（通常占站点总流量的80%）设置1-5分钟的短缓存，这部分页面占比极低不会占用过多缓存空间，即可挡住大部分突发流量；剩下80%的长尾低访问页面走实时渲染，因为长尾请求本身流量低，分到单进程的并发不会超过承载阈值。
  • 第二层做静态组件缓存：对CMS中不区分用户、更新频率低的通用组件（页头、页脚、导航栏、固定广告位等）做独立渲染缓存，每次渲染页面时直接复用预渲染好的组件内容，可将单页面渲染耗时从数百毫秒压缩到100ms以内，大幅提升单进程的并发承载上限。
• 优化SSR引擎参数配置
  不要盲目调高concurrency、timeout、maxRenderTime阈值，按照实际承载能力调整参数：
  • 将concurrency参数下调到单进程可稳定承载的数值（1核进程建议设为4），超过阈值的请求不要在单进程队列排队，直接转发到其他空闲SSR实例，避免排队超时。
  • 将maxRenderTime从默认的300000下调到10000以内，渲染时长超过阈值的请求直接终止，避免异常慢请求长期占用进程资源拖垮整个渲染队列。
  • 增加一次重试逻辑：请求触发超时回退CSR之前，先转发到空闲SSR实例重试一次渲染，降低单次偶发慢请求导致的回退概率。
• 渲染性能优化
  升级到Angular 16+版本开启官方水合能力，移除渲染过程中不必要的API调用和逻辑判断，进一步压缩单页面渲染的CPU开销，提升单进程的并发承载能力。

内容的提问来源于stack exchange，提问作者Jan B.