開啟服務器端渲染(SSR) 的 SAP Spartacus 實例，運行在 CCV2 Pod 里，當下列情況出現時，可能會造成 pod 的重啟：

resource allocation for SSR container within JSAPPS storefront pod is not sufficient and is causing finally some restarts.

比如：

過去3天內，運行在 SSR 模式的 Spartacus 所在的 pod，有 178 個 restart 事件：

SSR pods will be restarted at the memory consuming at 65% ~70%.

SAP Spartacus 3.0 對服務器端渲染模式下內存參數的優化：

In version 3.0, it’s possible to optimize SSR in relation to the max-memory-restart parameter, without having to increase the memory further.

In general, even 2-3 GB of memory is usually enough for SSR.

Spartacus 3.0 做的關于 SSR 的優化：

https://sap.github.io/spartacus-docs/server-side-rendering-optimization/#enabling-the-ssr-optimization-engine

MAX thresholds for JSStoreFront SSR PODs

具體優化內容如下：

優化引擎將請求進行排隊

在隊列里剩下的請求被默認按照 Client-Side Rendering (CSR) 處理之前，先將一部分加入隊列中的頁面進行渲染。

如果頁面能夠在指定的 timeout 時間段內進行渲染，則在 SSR 模式下服務。

如果引擎因為服務器端渲染情況下花費了太長的時間，則回歸到默認的客戶端渲染模式。此時被渲染的頁面被存儲在內存里，用于響應接下來的頁面請求。

CSR app 響應頁面請求時，帶有 Cache-Control:no-store 的字段，這樣確保其不會被 caching layer 緩存。

注意：CSR renders should never be cached. 相反的，渲染好的 SSR 頁面必須被緩存(例如使用CDN). 這樣，確保接下來的請求不會給 SSR 服務器造成負載。

所有這些優化操作，減小了 SSR 服務器的負載，以及 fallback 到 CSR 的次數。

啟用 SAP Spartacus 3.0 SSR Optimization Engine 的源代碼：

https://sap.github.io/spartacus-docs/server-side-rendering-optimization

import { ngExpressEngine as engine } from '@nguniversal/express-engine'; import { NgExpressEngineDecorator } from '@spartacus/setup/ssr';[...]const ngExpressEngine = NgExpressEngineDecorator.get(engine);[...]// In the app() functionserver.engine('html',ngExpressEngine({bootstrap: AppServerModule,}) );

總結

以上是生活随笔為你收集整理的SAP Spartacus 服务器端渲染处理内存泄漏的准则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。