背景
線上APP有一個下拉重繪的請求,大部分時間下拉重繪很快,偶發性下拉重繪請求介面特別慢,單獨請求介面的時候都很快,懷疑是網路波動問題,因此有了這篇文章
一.復現請求慢的情況



二.charles相關知識
1.顯示模式
(1) Structure形式如下圖 優點:可以很清晰的看到請求的資料結構,而且是以域名劃分請求資訊的,可以很清晰的去分析和處理資料,

(2)Sequence形式如下圖 優點:可以看到全部請求,這里的結果以資料請求的順序來顯示,最新的請求顯示在最下面

綜上,兩種形式各有千秋,structure 適合對單一系列的訪問請求從宏觀上進行把握,可以快速定位,sequence 適合精確定位內容,因為每條sequence 都有size,status等屬性資訊,方便快速定位這條結果的價值.
2.相關名詞解釋
Filter : 過濾,可以輸入關鍵字來快速篩選出 URL 中帶指定關鍵字的網路請求
Overview : 查看這次請求的詳細內容,例如耗時詳細列車了請求開始時間、結束時間,回應開始時間、結束時間,總耗時、DNS耗時、網路延時等,對于Size也詳細列出了請求頭大小、回應頭大小、壓縮比例等內容,
URL:進行網路請求的鏈接;
Status:當前狀態,complete表示請求完成;
Responce Code:回傳碼,不同的介面,不同的請求結果,回傳碼都不同;
Protocol:使用的協議;
Method:請求方式,如GET請求,POST請求等;
Kept Alive:判斷當前是否正在鏈接(活躍);
Content-Type:回應的content-type頭;
Client Address:客戶端的IP地址;
Remote Address:遠程服務器的IP;
Timing:
Request Start Time:接收到的第一個請求的第一個位元組的時間點
Request End Time:發送到客戶端的最后一個回應的最后一個位元組的時間
Response Start Time:回應開始時間
Response End Time:回應結束時間
Duration:整個請求回應持續時間,Duration=DNS+Connect+TLS Handshake+Response+Latency(應該是上面的加和)
DNS:所有選中的session決議DNS所花費的時間的總和
Connect:所有選中session建立TCP/IP連接所花費的時間總和
TLS Handshake--TLS協議握手時間
Request:請求耗費時間
Response:回應耗費時間
Latency:網路延遲時間和服務器處理時間
Charles shows a measure of the latency on each request on the Overview tab. Charles calculates latency by measuring the time taken between finishing sending the request and starting to receive the response. Therefore latency includes network latency and server latency, that is the time spent processing the request. For static requests the server is usually able to respond instantly, unless under load, so the latency figure mostly represents the network latency. For dynamic requests, or any request for which the server has to do some work, you can subtract an approximate network latency to determine how long the server spent processing the request. Charles在“概述”選項卡上顯示了每個請求的延遲度量,Charles通過測量完成發送請求和開始接收回應之間的時間來計算延遲,因此,延遲包括網路延遲和服務器延遲,即處理請求所花費的時間, 對于靜態請求,服務器通常能夠即時回應(除非處于負載狀態),因此延遲數主要表示網路延遲, 對于動態請求或服務器必須為之執行的任何請求,您可以減去近似的網路延遲來確定服務器處理該請求所花費的時間,Size:
Request Header :請求的頭部大小;
Response Header:回傳的頭部大小;
Request : 請求發送的大小;
Response:回傳資料的大小;
Total:所有資料大小;
Contents : 查看請求引數和回傳資料
Headers:發送請求的頭部資訊或者回傳的頭部資訊;
Text:請求的引數資訊或者回傳資訊的文本;
Hex:請求的引數或者回傳資訊的16進制表示;
JavaScript: 以js的形式格式化請求的引數或者回傳的引數;
JSON:請求引數或者回傳的資料JSON形式展示;
JSONText:請求的資訊或者回傳的資訊格式化成test形式;
Raw:發送的原生資料,包括了Headers和Text;
Summary: 查看發送資料的一些簡要資訊(主機,狀態碼,資料的型別,header和body大下,加載時間,總時間)
Chart: Summary中簡要資訊以圖表形式展示
Timeline:時間線,請求上傳、處理請求、回應組合的時間線,
Request - the time spent sending (uploading) the request (dark blue) Latency - the time spent waiting for network latency or processing time on the server (mid blue) Response - the time spent receiving (downloading) the response (light blue) 請求-發送(上傳)請求所花費的時間(深藍色), 延遲-等待網路延遲或服務器上的處理時間所花費的時間(藍色), 回應-接收(下載)回應所花費的時間(淺藍色),Sizes:回應資料的大小
Duration:與Overview中的Duration值是一樣的,不包含請求發送的時間,
Types:回傳的格式,application/json
Flow:應該是上傳下載速度與耗時的關系???
Notes: 其他資訊
三.問題分析
1

由上面兩張圖可以看出,整個請求程序刨除請求發送,耗時441ms,主要耗時在request上面了,由chart--timeline可以清晰的看出來請求時間組成,request占據了大部分的時間,可以推斷介面的回應速度還是可以的,更大的可能是網路波動造成的請求時間過長!
站在巨人肩膀上摘蘋果
https://www.cnblogs.com/henanleon/p/9902366.html
https://blog.csdn.net/weixin_42139375/article/details/105258019
https://www.jianshu.com/p/2baf3585a4c2
https://www.charlesproxy.com/documentation/using-charles/chart/
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/345.html
標籤:Java
