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

发布于 2022年 05月 19日 13:10

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 里查看。

推荐文章