开启服务器端渲染(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,}));
