我们在 Spartacus 前端激活了 SSR，并尝试测试它是否有效。为此，我们步进 SSR 并在生产模式下运行它。之后，我们使用 JMeter 创建 10 个并发用户请求两个简单 CMS 站点的负载。还添加了一个检查来验证答案实际上是 SSR 响应，而不是 CSR“空索引 html”。大约 80% 的请求没有进行 SSR，而是回退到 CSR 响应。如果我们将并发用户数减少到只有 2 个，则大多数情况下都有效。
为了防止这是由我们的自定义之一引起的，我们使用 Spartacus OOTB 代码运行相同的实验，并产生了相同的结果。
我们的 SSR 优化选项如下:
const engineConfig: SsrOptimizationOptions = {
timeout: 5000, // spartacus default: 3000
maxRenderTime: 300_000, // spartacus default: 300_000 (5min)
concurrency: 20, // spartacus default: 20
cache: false,
cacheSize: 20,
debug: false,
};
SSR 引擎能够渲染这么多的并发请求吗？如果缓存被激活，它就可以正常工作。但我们有数千个页面，我们很可能无法缓存每个页面。
最佳答案
单个实时 SSR 服务器无法处理大负载。为了缓解性能问题，您可能需要 a cluster of Node.js processes和 2 层缓存:用于渲染的 html(在 CDN 上)和 OCC API 调用。
如果您拥有的页面数量并不大，或者您可以考虑提前预渲染/SSG(服务器端生成)所有页面并将输出 html 文件放入 CDN，而不是实时 SSR .
作为核心团队，我们将很快发布有关《斯巴达克斯》最佳 SSR 设置的新文档。但在发布之前，让我分享一下可能已经对您有所帮助的早期草稿(来自 PR ):
关于sap-commerce-cloud - 如何让斯巴达克斯服务器端渲染在负载下执行？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/72598894/