关于 Spartacus 服务器端渲染出现 timeout 的一个具体例子的分析

Node Express server listening on http://localhost:4200

SSR rendering exceeded timeout 2000, fallbacking to CSR for /
SSR rendering exceeded timeout 2000, fallbacking to CSR for /xyz
SSR rendering exceeded timeout 2000, fallbacking to CSR for /p/xyz

Rendering of / was not able to complete. This might cause memory leaks!
SSR rendering exceeded timeout 2000, fallbacking to CSR for /p/xyz

Rendering of /p/xyz was not able to complete. This might cause memory leaks!

Rendering of /p/xyz was not able to complete. This might cause memory leaks!

从上面的错误日志，我们可以推断出，应用程序在 SSR 中的渲染，对于 /，/xyz 和 /p/xyz 这几个页面请求来说，没有成功完成。

这可能是由各种原因引起的，例如挂起的异步任务（例如挂起的 OCC API 调用），也可能是应用程序在渲染完成之前因为运行时异常而崩溃导致的。

可以在 app.module.ts 里添加如下的调试信息，打印 SERVER_REQUEST_URL 和 SERVER_REQUEST_ORIGIN 的值。

export class AppModule {
  constructor(
    @Optional() @Inject(SERVER_REQUEST_URL) protected serverRequestUrl?: string,
    @Optional() @Inject(SERVER_REQUEST_ORIGIN) protected serverRequestOrigin?: string
  ) {
    console.log({ serverRequestUrl, serverRequestOrigin });
  }
}

可以在 Dynatrace 中找到这些请求 -> 去看看是否可以看到子 API 调用。 不幸的是，如果有一些没有及时返回，那么 Dynatrace 将不会将它们记录在该请求下（请求以 DT 的 CSR 响应结束）。

可能值得弄清楚在出现这种问题时，客户到底将 maxRenderTime 设置为什么值。 当请求超时并返回 CSR 时，原始的 SSR 渲染仍然在后台运行。 但是本文开头的这些日志表明后台渲染也永远不会完成 -> 它达到了 maxRenderTime.

如何解释同样的 API，在 SSR 和 CSR 模式下的响应时间相差很大？

来自 SSR 的 API 调用可能没有命中 CSR 版本所命中的同一 API 节点实例。也许在一个低使用率的系统上，有一些 API 节点没有完全预热，这些需要很长时间。

Dynatrae 不会记录没有正常完成的 API 请求。

确保 SSR 服务器的 ip 地址，没有出现在 API pod 的 IP restriction 里。

IP 过滤位于端点，实际上是 Apache 配置中的虚拟主机。 SSR 注入了与 CSR 相同的 API 端点。因此，与 API 的 SSR 连接将发送到 Apache，然后由 Apache 反向代理到 API 节点。所以对应的 log 应该在 Apache 里查看。