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 的优化：
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
