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