2021-10-28 SAP Spartacus SSR 性能方面的一些學習筆記

如果客戶已經擁有 cdn 緩存，可以不啟用 cache:true, cachesize:xxx 。 這種記憶體緩存功能僅适用于沒有生産就緒 cdn 的簡單店面。也就是說，如果客戶沒有任何外部緩存服務（akamai / cloudflare / 其他），他們可以嘗試，至少暫時，使用 ssr 服務記憶體緩存和 cache: true （最好也使用 cachesize）。

concurrency 值設定得過大也不合适，這樣會導緻額外的性能下降。當太多請求同時命中一個 pod 時，請求可能會逾時。

我們引入了一個數組，用來記住 callbacks.

我們僅在渲染完成或 maxrendertime 到達時清除數組。

如果單個 url 的渲染任務花費大量時間（例如一分鐘），則對該 url 的所有請求顯然都會逾時。 但是我們将存儲它們的回調直到 maxrendertime 過去。 這意味着對于 1.5 分鐘，數組可能會随着單個 url 的增長而增長。 隻有在 1.5 分鐘後，我們才放棄并清除數組。 您可以同時渲染 50 個 url。

我們可以在更新檔中潛在地改進/優化：立即從數組中删除任何逾時回調。 [由于所需額外重構的複雜性，我們決定不這樣做]。

除此之外，根據流量，增加 pod 中的記憶體限制可能會有所幫助。

此外，如果渲染任務真的（由于任何原因）“永遠”挂起，無論如何都可能導緻記憶體洩漏。

請注意 concurrency: 50（在 ssroptimizationoptions 中）意味着 optimizedssrengine 最多将執行 50 個并行渲染任務。

啟用 reusecurrentrendering，這意味着：一次最多可以渲染 50 個不同的 url（不管并行請求的數量）。

這意味着：如果您一次發送 51 個或更多不同 url 的并行請求，則第 51 個 url（以及更多）的請求将立即回退到 csr。 這是設計使然。

此外，如果您啟用 debug:true，那麼您将看到控制台消息 csr fallback: concurrency limit exceeded (edited)

一般來說，并發請求越多，無論是否緩存 occ，平均響應越慢。

當 occ 響應沒有被緩存時，pdp 的 ssr 響應時間可能會有所不同，但當隻有 1 個并發請求時，maximum 甚至可以達到 7 秒。

與未緩存 occ 時相比，緩存 occ 時 ssr 響應時間平均快約 3 秒。

如果 occ 未緩存，但使用靜态基站配置而不是動态配置 - 平均響應時間更快，例如 從 1 到 15 個并發請求，我們使用靜态 basesite 配置節省了 0.1-0.5 秒

理想情況下，如果可能，盡量避免 ssr 伺服器過載。 相反，您應該在 ssr 之前設定一個帶有緩存的 cdn。 并且您應該巧妙地對緩存進行部分預熱，這樣 ssr 伺服器就不會因為所有預熱請求而立即受到攻擊。 緩存失效和重新預熱也應該在某些部分巧妙地發生。

給 ssr 添加 occ api 本地緩存用于測試的代碼：

然後在 app.module.ts 裡添加：