企業級 JavaScript 應用部署在生產系統並執行後，如果出現效能問題，則找出引起這些效能問題的根源，往往不像找出引起執行時故障或者異常的根源那麼簡單。JavaScript 應用的效能問題往往表現在使用者請求響應時間的下降，系統可用資源的降低甚至耗盡。

本文以一個開源的電商 Storefront 企業級應用[Spartacus](https://github.com/SAP/spartacus)為例，來給大家分享 JavaScript 應用在生產系統遇到效能問題時，開發人員應該如何去分析可能的原因。

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

當使用者在瀏覽器裡發起一個對 Storefront 的訪問請求之後，會經由下列元件進行處理。因此從理論上講，所有這些元件都可能成為導致出現效能問題的根源之一。

- 負載均衡伺服器
- 執行 JavaScript Storefront 的 Web Server(比如 Nginx，Apache)
- Server.js：JavaScript Storefront 執行在伺服器端渲染模式下的實現
- CDN
- API 伺服器
- 資料庫

我們可以使用 Dynatrace 這個強大的平臺來分析 JavaScript 應用的執行效能資料。Dynatrace 中的服務選單是開始效能分析的推薦入口，因為這裡能看到上述所有元件的效能資料。

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

視覺化所有元件及其響應時間貢獻的一個推薦的方法，是儘可能從呼叫的最外層開始，即 JavaScript Storefront 執行網站對應的 Apache 服務，在本例中為 www.demo.com:443.

單擊右側的圖示 `...` 並選擇 Service Flow. 在隨後顯示的頁面中，最好將分析時間的範圍縮小到有明顯效能問題的時間視窗。 另一種方式新增響應時間過濾器，以僅關注響應時間最慢的那些請求。

例如，設定過濾器響應時間 >= 6s，將允許僅視覺化那些響應時間等於或者超過 6 秒的請求熱點。

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

需要強調的是，Service Flow 圖表裡顯示的每一個節點都依賴於前一個節點，因此在分析一個時間段的效能資料時，可能相鄰若干節點的響應時間百分比通常都會很高，直到遇到真正有效能問題的服務為止。例如，如果效能瓶頸是資料庫，那麼它之前的所有層也都將參與整體貢獻，即使它們只是在簡單的等待資料庫操作的結束。

例如，在上圖所示的場景中，瓶頸似乎是 Node.js 應用程式，因為響應時間的百分比下降，發生在這個 Node.js 程式之後。

透過單擊任何層並使用 `...` 按鈕，選擇響應時間熱點選項，可以檢視每個級別的單個貢獻者。 例如，從 `www.demo.com:443` 開始，我們發現一個特定的請求，對總體的響應時間百分比貢獻最大。

既然我們猜想是 Node.js 應用造成的效能問題，可以進一步檢視 `jsapps` 的效能資料，如下圖，其 Code Execution 花費了 6.19 秒。
![](https://img-blog.csdnimg.cn/img_convert/807bbe9f712fc62344cc5adf8d62825f.png)

點選上圖的 Code Execution，進入明細頁面，再重複點選 `...` 繼續檢視，直至發現對響應時間 6.19 s 貢獻最多的那一行函式呼叫。

執行在生產系統中的企業級 JavaScript 應用的效能問題分析指南

相關文章

最新文章