測試目的:
cacti監控流量準確性
測試環境:
PC1:(windows) VM host
PC2:(Centos) VM guest & cacti server
測試流程:
由pc1使用winscp上傳約1.3G檔案到pc2
cacti監看pc2網卡inbound流量是否與winscp上傳頻寬符合
以下是winscp傳檔與cacti的流量監控截圖
<winscp上傳>
<cacti流量監控圖>
除了數據看起來有誤差以外,cacti單位是bits,而winscp單位是Bytes
這樣算起來,監控的流量會差了8倍?
winscp由"傳輸流量"去乘以"總共傳輸秒數"計算檔案大小是符合的
23.18MB/s * 57s = 1.29GB
那會是cacti的單位有問題嗎?
(cacti流量監控有變更設定成64bit,已可監控500Mb/s以上的流量)
先謝謝各位前輩。
一個是檔案傳輸量,
一個是網路通訊量 本來就不一樣,
不同PC間透過網路傳輸檔案,
要把檔案切包,打成軟體所用的協議包,
再包成IP包,還要再包一層乙太包...
結果當然是網路通訊量勢必要大於檔案傳輸量
兩者間的差異則可用來觀察用什麼方式什麼軟體
作檔案傳輸會比較省網路頻寬用量,
不過也要看是LAN還是WAN,會有不一樣的考量,
測量點也會有所不同
考慮頻寬之外,傳輸所需費用的時間也是要評估,
看怎樣最省頻寬又最有效率(或符合需求)...
先謝謝wwx大的提點
目前小弟發現的問題是
winscp的檔案傳輸量是23.18MB/s,單位是Bytes/sec
而cacti監控到的傳輸量是39.28Mb/s,單位是bits/sec
如果換算成相同單位bits/sec來比較的話
winscp傳輸量為23.18MB/s * 8bits=185.44Mbits/sec
而cacti=39.28Mbits/sec
winscp傳輸量遠遠大於cacti監控到的傳輸量(兩者差了4.7倍)
以上是小弟對cacti監控單位的疑惑
謝謝wwx。
那不覺得所po的圖哪裡怪嗎?
winscp 是估1分鐘傳完,
而cacti的圖是13:45~13:50費時5分鐘,
用 39.28Mbits/sec * (60secs * 5) = 11784Mb = 1473MB = 1.44GB
和你計算winscp
23.18MB/s * 57s = 1.29GB
是不是就能符合所要的想像了呢~
cacti的圖感覺就像頻寬最多只能用到40Mb/s,
所以檢查一下上傳檔案的目的位置路由為何?
頻寬卡在哪個點限制住了?
還是有軟體作限流呢?
而winscp的傳輸完畢其實只是軟體已經把資料丟進緩存區完畢...之後都是背景作業,
所以這緩存有點大,可能800MB以上,
(4/5的時間在背景傳輸)
可以去研究這緩存是winscp本身的設計,
還是所運行的OS環境緩存會用到這麼大...
或者試試傳輸前看一下OS的記憶體用量和winscp的工作管理員中的記憶體用量,
然後再與傳輸完畢之前的狀態相比較,應該就能區分出來了吧...