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 裡檢視。