背景

上周接到一個性能問題的線上反饋：“浙江客戶xxx報表展示超過20秒，小明看了相關接口響應都在2秒內，希望我協助排查。”

聽完這個簡短的描述我猜測可能是客戶機房網絡問題，為什么這么說呢，從描述中我提取到這么幾個關鍵信息“個例，不是所有客戶”、“后臺響應很快”，給我的感覺好像是機房出口帶寬滿了，當然這只是猜測，需要拿出具體的證據。

初步排查

“信任但需要確認”，雖然我從研發口中得知后臺響應很快，但是為了查問題我還是把相關賬號要過來自己點了點，也看了后臺的access log的確不慢，通過瀏覽器的Network -> Timing奇怪的發現，有個提示會停留20s左右“CAUTION：request is not finished yet!（注意：請求尚未完成）”，之后才會展示各項指標耗時，但是耗時都不高。

這個表象似乎和我猜測機房出口帶寬滿的想法不謀而合，接下來就是剝繭抽絲，證實客戶機房網絡的確有問題，提供證據讓實施反饋客戶，客戶再去問候信息管理部，信息管理部再去問候運營商（ 和toG的客戶打交道千萬要謹慎，往往都會驚動一個鏈條上的人 ）。

由于我不是專業網工，對于網絡問題也只能憑借自己的二把刀經驗來做一些診斷，如果有不對的地方，請大家一定要指正。

ping -n 50 xxx.com

我首先通過ping的方式來觀察是否有丟包情況，結論是網絡良好，沒有任何丟包情況。

接下來我又通過Wireshark抓包分析，本機發出請求到收到響應的時間確實在2s之內，這樣看來報表展示慢和網絡似乎是沒關系，還需要繼續挖掘原因。

強烈推薦大家學習Wireshark，對于網絡學習、問題排查真的是一把利劍。

懷疑一切

之前提出的疑點偏后端領域，現在排查一圈下來矛頭指向了前端，那就接著挖。

我看了報表頁面內的js代碼，邏輯很簡單，就是ajax查詢數據然后調用前端框架的setData方法，到底是哪段js代碼把整個頁面渲染給拖慢了呢。

我甚至懷疑是不是觸發了jquery框架的某個bug，為了證實這一點我將請求數據那段從jquery切到了最原始的XMLHttpRequest，依然很慢。

要是瀏覽器能記錄這個頁面渲染過程中發生了什么，每個階段的耗時分布，那排查問題就方便多了，我想到了曾經用過的skywalking、jaegertracing這類鏈路追蹤工具，排查后端性能問題很是方便。

最終借助搜索引擎找到了chrome的Performance，請搜索“chrome 前端性能優化工具”詳細了解，真是好用，前后不到兩分鐘就找到了性能瓶頸點。

開始采集

F12-Performance->點擊  開始記錄->刷新頁面->等待頁面渲染完成->點擊  停止記錄

查看調用樹

點擊上圖紅框部分的Call Tree查看調用鏈路和每個節點的耗時，重點關注耗時占比較大的調用棧，如下圖所示拖慢整個頁面渲染的元兇是jCommon.js中的兩個設置表格樣式的函數。

這兩個函數的觸發時機在jCommon.js的$(function(){}中，屬于通用邏輯，之所以其他客戶沒有受到影響，是因為其他客戶對于表格的個性化設置沒有開啟，所以沒有執行，我大體看了一下邏輯內部有太多的遞歸+循環調用，遇到復雜（行列合并、嵌套）而且數據量大的表格就是一種噩夢，更細節的就不多說了，不是本篇的重點。

解決辦法

“讓專業的人干專業的事”，因為前端我并不擅長，所以我將這個問題的根治任務拋給了前端同學，這塊代碼是必須要優化的，太損耗性能。同時對于當下的問題我也給出了建議，在當前報表頁面暫時剔除這段邏輯，初衷是用來提升用戶體驗，現在看來已經嚴重影響到可用性。

總結

透過一個簡單的性能問題，聊聊筆者排查的思路和中途用到一些工具，最終借助瀏覽器的性能分析工具發現前端問題代碼，對于陌生的領域一款良好的工具可以降低排查的門檻，事半功倍。