1. 程式人生 > >網絡性能評價方法

網絡性能評價方法

script 優化 大小 偏差 浮動 pri 不同的 href down

網絡性能評價的實現

網絡的優劣會影響網絡交互的延遲時間、穩定性和速度,從用戶體驗上集中表現為打開頁面的速度緩慢。比方在較差的網絡並發的請求數會被降低,以避免網絡性能由於堵塞而進一步惡化。

針對不同網絡品質的優化的前提就是要有一種方法來度量網絡的品質。

眼下度量網絡的品質的方法假設僅以網絡連接類型來區分,比方2G, 3G, Wifi等。無法有效感知到當時的網絡狀態。在同一網絡連接類型下,網絡的品質仍有大幅波動。可能會由於堵塞以及線路上問題導致延遲上抖動(jitter)、丟失數據包、數據包損壞等情況。

在現實場景中,比方繁忙時段,或者處在信號不好的區域時(如交通工具上),使用網絡類型來推斷當時的網絡品質會有非常大偏差。

本文基於對一段時間的網絡數據的記錄。進行算法處理,能夠測出一個衡量當時網絡狀態的指標(MI: Measurement Index)。詳細應用到移動設備上時,考慮到計算量的問題,能夠使用近似算法減小計算的復雜度。

眼下的使用的算法是結合歷史數據進行統計,即執行指數平滑算法。這樣理論上由於同一時候使用了本次及之前的歷史的數據進行計算。能夠將單次統計的數據量降低。

網絡數據的定義是通過模擬測試環境錄制得來。當中包括兩個主要內容:
1. 定義網絡評測的參數
2. 定義網絡狀態區間範圍

在實際應用時,還須要考慮數據採集的區間和數據量。以及數據的平滑處理。

網絡評測的參數

經過對照評估下面六個參數相應於latency和bandwidth的設定。得到數據例如以下:
1. Speed, 傳輸速率:由收完數據的時間除去所收取的數據大小。
2. Header Received: 收到響應頭的時間 (即TTFB)。


3. Connected: 連接到主機的時間。


4. Sent: 在Java層完畢調用完畢發送請求的時間。
5. DNS Resolved: DNS解析的時間。
6. Finished: 整個請求完畢的時間。
技術分享

對照分析各參數中位數與網絡狀態(rate)後,發現下面參數與網絡狀態的關聯關系,當中Header Received的關聯關系為正相關。

所以定義由Header Received時間定為網絡衡量指標

定義網絡狀態區間範圍

關於網絡狀態範圍,由於網絡的波動性。不能限定在詳細的一個值的區分。

這裏使用K中值分類法(R Script: compareData.R)。

將數據分為四個簇。依次取出其設定範圍。再以眼下測試發現最大值分布在12000左右(約為6000延遲)。 所以使用13000,即最大延遲數。進行歸一化處理。

下圖表示的為分為四個簇的情況(每一項數據為一個URL測試5次所得結果):
技術分享
當中cluster 4最佳,cluster 1為最差的區間, 為保守起見,在眼下的實現將cluster 1與cluster 2合並來看。

定義數據分析的時間段

依次採集分析2x1URL, 5x1URL,5x2URLs, 5x4URLs及3x1URL數據。對照各種情況下數據聚合的情況。

當中2x1URL 表現數據不足,四個簇不能非常好的分隔:
技術分享
這時的每一項值的數據量為50條左右。

當3x1URL時。每一項值的數據量為80條上下,四個簇重合部分已經有非常好的改善:
技術分享
由上面可知。假設使用獨立樣本進行計算。50筆數據較難獲得有效的樣本數據。至少須要80筆數據,才幹得出較合適的統計。而移動網絡下,特別是2G網絡下,80個請求會耗時太久,不利於及時體現當前網絡數據。

眼下的使用的算法是結合歷史數據進行統計,即執行指數平滑算法。這樣理論上由於同一時候使用了本次及之前的歷史的數據進行計算,能夠將單次統計的數據量降低。

定義數據的樣本大小及採集周期

眼下選定最小採集樣本為15筆請求,包括失敗的請求,當中失敗的請求視為一次最大延遲記錄(取值見上面的討論)。 最小採集周期為30秒,最大採集周期為4分鐘。

考慮到網絡的變化特性,一是不能太快跳變,二是及時逼近。另外在移動網絡下。數據量可能達不到採集的要求,必須有效地利用歷史數據。所以系數的選擇須要考慮到兩個方面:一是收斂速度,二是兼顧歷史數據(利用歷史數據進行計算。並避免數據不準導致的誤判。)。

這裏存在三個變量: 採集的周期(t)。採集的樣本數(n)及平滑系數(a)。
採集樣本數是指最小能夠用於統計運算的數據數量。依據模擬測試(R腳本為simulatorPhase.R), 推斷數據集的大小的波動性能夠在平滑系數的輔助下達到一定的穩定性(平滑系數越小,數據分布越穩定。但收斂速度越慢.)。 比方下圖中使用樣本數15、平滑系數0.3的組合能夠達到樣本數20、平滑系數0.4組合的標準差範圍。

(平滑系數越大標準差越大!)

採集樣本為20。平滑系數為0.4(總數據量4000)。結果的標準差為579.87(非定值):
技術分享

採集樣本為15,平滑系數為0.4(總數據量4000),結果的標準差為589.16(非定值):
技術分享

採集樣本為15,平滑系數為0.3(總數據量4000)。結果的標準差為576.41(非定值):
技術分享

採集樣本為15,平滑系數為0.6(總數據量4000),結果的標準差為872.23(非定值):
技術分享

採集周期是指最小的數據採集時間,在此時間內僅僅負責收集數據,不進行計算。在採集周期內可能並不會收集到足夠的數據。就會延長到一個最大採集周期。
採集的周期的大小取決於最小採集樣本的大小。眼下設定為30秒。

最大採集周期的選定,取值於移動網絡下,以無圖模式一分鐘瀏覽一個新浪新聞頁面。達到採集樣本數量的時間。即4分鐘。

下圖為上述參數在實際測試過程中觀察到的Measurement Index分布的情況, 在數據演化將近6次(約3分鐘)後維持到6385上下。
技術分享

定義數據的平滑系數

不同的平滑系數會一個處理波動時的浮動範圍,表示無法明白判別的區域,歸為較好的網絡處理。由此定義了實現時使用的模糊區間。

測試對照了多個候選的系數。以0.3及0.65為例說明例如以下。

平滑系數:0.3

指數0.3是假設網絡環境相對穩定,但受網絡抖動的影響會有波動。

在計算時選擇經過多樣本獲得的歷史數據的比重大於新取得的單樣本數據。缺點是會造成逼近速度變緩, 近8次逼近到目標值(相差200以內)。

再模擬兩次數據統計的波動。

單次統計數據約為2000。若分成兩次統計,可能會遇到一次3500,後一次500的大幅波動。應用系數0.3後統計結果保持在平均值2000的上下200的範圍, 相應於指數上下浮動0.03。
下面為其示意圖:
技術分享

8次逼近所需時間視最小採集周期而定,普通情況下約為4分鐘時間。

考慮大幅波動時的標準差,以3000~1500的波動為例。其標準差為:447.56。


技術分享

系數0.3最大的優勢在於適應小樣本數據的情況。詳細之前的討論。為了彌補基本的缺點,將在一個網絡下第一次計算時。先使用系數0.5, 再調整為0.3。效果例如以下:
技術分享

下面為實際測試結果(latency:2000,bandwidth 80kbps, standard MI:~2500):
技術分享

平滑系數:0.65

當選取0.65作為系數時,當前值所占的比重更高。須要3次運算逼近到設定值(130以內,占比小於1%)。

如上模擬兩次數據統計的波動。這時統計結果保持在平均值2000的上下約800(逼近於777)的範圍。即設定的界定值前後800相應於性能指數上下浮動0.06。
技術分享

考慮大幅波動時的標準差,以3000~1500的波動為例,其標準差為:381.9。較系數取0.5時並沒引入太多的誤差,卻將收斂所用的次數降低了2次。
技術分享

與實際場景的相應

與現實場景的相應關系例如以下(收集的現場數據):

Scenario Latency Index
包括地鐵繁忙時間的數據(2G) 500~6000 19~100
地鐵一般場景(2G) 100~400 5~64
公司座位
200~500 32~52
3G&Wifi 50~80 0~4

下面為其分布示意圖(橫軸依次代表上表中的五項,請忽略第3項數據):
技術分享

參考

  • 網絡性能評價

網絡性能評價方法