建站
咨詢
售后
建站咨詢
新聞中心
背景
上周接到一個性能問題的線上反饋：“浙江客戶xxx報表展示超過20秒，小明看了相關接口響應都在2秒內，希望我協(xié)助排查。”
成都創(chuàng)新互聯(lián)是一家專業(yè)提供仲巴企業(yè)網站建設,專注與網站設計制作、成都網站制作、html5、小程序制作等業(yè)務。10年已為仲巴眾多企業(yè)、政府機構等服務。創(chuàng)新互聯(lián)專業(yè)網站設計公司優(yōu)惠進行中。
聽完這個簡短的描述我猜測可能是客戶機房網絡問題，為什么這么說呢，從描述中我提取到這么幾個關鍵信息“個例，不是所有客戶”、“后臺響應很快”，給我的感覺好像是機房出口帶寬滿了，當然這只是猜測，需要拿出具體的證據。
初步排查
“信任但需要確認”，雖然我從研發(fā)口中得知后臺響應很快，但是為了查問題我還是把相關賬號要過來自己點了點，也看了后臺的access log的確不慢，通過瀏覽器的Network -> Timing奇怪的發(fā)現(xiàn)，有個提示會停留20s左右“CAUTION：request is not finished yet!（注意：請求尚未完成）”，之后才會展示各項指標耗時，但是耗時都不高。
這個表象似乎和我猜測機房出口帶寬滿的想法不謀而合，接下來就是剝繭抽絲，證實客戶機房網絡的確有問題，提供證據讓實施反饋客戶，客戶再去問候信息管理部，信息管理部再去問候運營商（ 和toG的客戶打交道千萬要謹慎，往往都會驚動一個鏈條上的人 ）。
由于我不是專業(yè)網工，對于網絡問題也只能憑借自己的二把刀經驗來做一些診斷，如果有不對的地方，請大家一定要指正。
ping -n 50 xxx.com
我首先通過ping的方式來觀察是否有丟包情況，結論是網絡良好，沒有任何丟包情況。
接下來我又通過Wireshark抓包分析，本機發(fā)出請求到收到響應的時間確實在2s之內，這樣看來報表展示慢和網絡似乎是沒關系，還需要繼續(xù)挖掘原因。
強烈推薦大家學習Wireshark，對于網絡學習、問題排查真的是一把利劍。
懷疑一切
之前提出的疑點偏后端領域，現(xiàn)在排查一圈下來矛頭指向了前端，那就接著挖。
我看了報表頁面內的js代碼，邏輯很簡單，就是ajax查詢數(shù)據然后調用前端框架的setData方法，到底是哪段js代碼把整個頁面渲染給拖慢了呢。
我甚至懷疑是不是觸發(fā)了jquery框架的某個bug，為了證實這一點我將請求數(shù)據那段從jquery切到了最原始的XMLHttpRequest，依然很慢。
要是瀏覽器能記錄這個頁面渲染過程中發(fā)生了什么，每個階段的耗時分布，那排查問題就方便多了，我想到了曾經用過的skywalking、jaegertracing這類鏈路追蹤工具，排查后端性能問題很是方便。
最終借助搜索引擎找到了chrome的Performance，請搜索“chrome 前端性能優(yōu)化工具”詳細了解，真是好用，前后不到兩分鐘就找到了性能瓶頸點。
開始采集
F12-Performance->點擊 開始記錄->刷新頁面->等待頁面渲染完成->點擊 停止記錄
查看調用樹
點擊上圖紅框部分的Call Tree查看調用鏈路和每個節(jié)點的耗時，重點關注耗時占比較大的調用棧，如下圖所示拖慢整個頁面渲染的元兇是jCommon.js中的兩個設置表格樣式的函數(shù)。
這兩個函數(shù)的觸發(fā)時機在jCommon.js的$(function(){}中，屬于通用邏輯，之所以其他客戶沒有受到影響，是因為其他客戶對于表格的個性化設置沒有開啟，所以沒有執(zhí)行，我大體看了一下邏輯內部有太多的遞歸+循環(huán)調用，遇到復雜（行列合并、嵌套）而且數(shù)據量大的表格就是一種噩夢，更細節(jié)的就不多說了，不是本篇的重點。
解決辦法
“讓專業(yè)的人干專業(yè)的事”，因為前端我并不擅長，所以我將這個問題的根治任務拋給了前端同學，這塊代碼是必須要優(yōu)化的，太損耗性能。同時對于當下的問題我也給出了建議，在當前報表頁面暫時剔除這段邏輯，初衷是用來提升用戶體驗，現(xiàn)在看來已經嚴重影響到可用性。
總結
透過一個簡單的性能問題，聊聊筆者排查的思路和中途用到一些工具，最終借助瀏覽器的性能分析工具發(fā)現(xiàn)前端問題代碼，對于陌生的領域一款良好的工具可以降低排查的門檻，事半功倍。
名稱欄目：拋磚系列之前端性能分析工具
地址分享：http://fisionsoft.com.cn/article/dphgsjj.html
