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

語言: CN / TW / HK

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

本文以一個開源的電商 Storefront 企業級應用Spartacus為例,來給大家分享 JavaScript 應用在生產系統遇到效能問題時,開發人員應該如何去分析可能的原因。

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

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

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

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

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

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

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

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

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

既然我們猜想是 Node.js 應用造成的效能問題,可以進一步檢視 jsapps 的效能資料,如下圖,其 Code Execution 花費了 6.19 秒。

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