理論上來說，一旦使用者請求到達 Spartacus SSR 伺服器，通常有三個潛在的響應時間貢獻者，其中最後一個也可以細分成多個潛在的效能瓶頸：

- 執行 Node.js 程式碼所花費的時間
- 在 apache 層上向 OCC 層請求所花費的時間
- 請求 OCC 層在 API 伺服器上花費的時間

對於第三點，下列原因都可能造成 API 伺服器響應時間過長：

- API pod 上的資源耗盡
- DB 鎖定/DTU 耗盡
- 對公共網路的請求（例如 payment 提供商）
- 執行緒/資源鎖定和爭用
- 程式碼執行

![](https://img-blog.csdnimg.cn/img_convert/3ea302d7e2bfb14728628a6b920b135a.png)

如果發現程式碼執行是響應時間的主要貢獻者，接下來的調查應該集中在 Node.js 程式碼和 SSR 伺服器資源利用率上。

如果最大貢獻者是 OCC 請求，則可以重複上述相同步驟，以確定這些請求中最慢的最大貢獻者。 例如，使用 api-demo.com:443 層的響應時間分析，將有助於瞭解絕大部分響應時間，到底是花費在 API 伺服器、資料庫還是對公共網路的請求上。

在此示例中，我們將從 www.demo.com:443 開始，然後單擊 `PurePaths`. 在隨後的單個請求分析中，新增響應時間過濾器，以僅保留響應速度最慢的子請求，有助於我們把調查精力放在真正的效能瓶頸上。

![](https://img-blog.csdnimg.cn/img_convert/c0dee1ecc91583fd19c18b8f6c171f4c.png)

單個請求的 PurePaths 將顯示在程式碼或 apache 上花費的任何時間以及每個資料庫查詢和對外部系統的呼叫。 當我們有興趣準確瞭解瓶頸在哪裡時，這個功能極其有用，甚至可以深入到單個的資料庫查詢。 不足之處是 PurePaths 一次只能檢視一個請求。

![](https://img-blog.csdnimg.cn/img_convert/2f7e233f01be5a03c34ff49f162f2bcf.png)

從上面可以清楚地看出，至少對於我們選中的特定的請求來說，時間幾乎完全花在了 Node.js 程式碼的執行上。這提示我們，需要檢查一下 jsapps pod 上的 CPU 和記憶體利用率。

資源利用率的分析會根據使用 CSR 或 SSR 模式而略有不同。

在這兩種情況下，Dynatrace 會顯示相對於 VM 的 CPU 使用率。 例如，如果一個 pod 有 8 個核心，而 VM 有 16 個核心，當 Dynatrace 顯示 CPU 為 50% 時，它實際上表示 CPU 為 100%。

當 Spartacus 工作在 CCV2 的 CSR 模式下時，CSR 容器本質上只是一個將請求路由到 OCC 層的 nginx Web 伺服器。 在選擇 Nginx 和 nginx jsapps-* 後，可以從 Dynatrace 的技術和程式頁面中檢視 CPU 和記憶體使用率。

![](https://img-blog.csdnimg.cn/img_convert/43e21f40876eb123811a795321659c6f.png)

隨後的頁面將顯示所選任何給定指標的平均利用率。 單擊單個 pod 將進入其程式詳細資訊頁面，其中可以檢視有關 cpu/記憶體利用率和重新啟動時間的資訊。 對於 CSR，有關 CPU 和記憶體的詳細資訊都位於系統效能選項卡下。

![](https://img-blog.csdnimg.cn/img_convert/d2bb40045360924231bb5240d7e968dd.png)

如果發現 CPU 或者記憶體利用率過高，通常表明 CCV2 Pod 沒有足夠的副本來處理所有請求，因此水平擴充套件將是一種可能的解決方案。

執行在 CCV2 環境上的 Spartacus Storefront 如果出現效能問題該怎麼分析

相關文章