[JavaScript Storefront](https://launchpad.support.sap.com/#/notes/3130505) 應用程式的效能問題的表現形式有多種，最典型的是響應時間(response time)的惡化，甚至由於資源耗盡導致的網站完全當機。 由於 JavaScript Storefront 涉及許多元件，因此確定效能問題的根源可能具有挑戰性，如下圖所示：

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

一個客戶請求傳送到 JavaScript Storefront 之後，Storefront 應用對該請求的處理，將涉及以下元件，所有這些都可能是問題的根源：

- 客戶端（瀏覽器或 CDN）
- Apache Web 伺服器（透過 JS Storefront vhost），也就是 Commerce Cloud 支援的 redirect endpoint 功能的實現
- Nginx Web 伺服器（jsapps pod 的 jsapps 容器）
- Server.js（jsapps pod 的 jsapps-ssr 容器 - 僅在啟用 SSR 模式時相關）
- CDN（上面沒有說明，但是如果使用 CDN，那麼它將位於此級別 - 如果未找到快取的響應，請求可以在此處結束或繼續到源伺服器）
- Apache Web 伺服器（透過 API vhost）
- 商務網路服務（API pod）
- 資料庫

一般情況下，我們可以從 Dynatrace 的 Services 皮膚開始，這裡能看到不同類別的服務的平均響應時間，最慢的響應時間，以及每分鐘處理的請求數量。

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

作為效能分析的切入點，我們可以從應用響應使用者請求的最外層服務開始入手，單擊右側的服務列表中的 `...` 符號。

下圖的含義是，設定過濾器的值為 `響應時間 >= 6s`, 這將允許僅視覺化最慢請求的響應時間熱點。

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

另外注意，Promise.all 這個 API，如果使用不恰當，也可能帶來效能問題，特別是用大量的操作呼叫它的時候。

例如，我們有一個 ids 陣列，需要從資料庫中根據 id 讀取實體。 如果列表中有 10 個 id，那不是問題，但如果有 1000 個的話，不建議一次性從資料庫中完成全部的資料讀取操作。一種更優的解決方案是，採用批次操作 + 遊標的方式，從資料庫中讀取資料。

使用 Dynatrace 對 Node.js 應用的效能資料進行分析

相關文章