#大有學問# #頭條創作挑戰賽#
性能測試，如果一旦有網絡瓶頸，那性能測試的所有資料都将失真，沒有了價值，是以，網絡性能瓶頸，就成為了一個非常關鍵問題了。下面我就給大家支三招。
第一招：預判
做伺服器性能測試，一般都會通過抓包，擷取接口封包。在抓取封包的時候，可以看下封包的響應體大小。
有的抓包工具，可以看到響應體的封包size大小。
像我這個，總頁面很大，但是，單請求的大小不大。這種，就是前端頁面有優化空間，單接口優化空間不大。這個接口傳回的資料量也就10條，再怎麼樣，總資料大小，也不可能大到哪裡去，是以，這種接口資料量，一般不會導緻網絡瓶頸。
如果，你抓包，看到某個接口傳回非常多的資料量，甚至一次調用，把所有的資料都傳回，然後，前端自行分頁。這種接口，大機率會出現網絡帶寬瓶頸。
我曾經做過一個項目，因為功能上要做級聯，是以，接口一次性把所有資料傳回給前端，然後，前端根據傳回資料，實作資料關聯。這種，肯定會有網絡瓶頸出現。結果，我做性能測試時，企業百兆光纖網，都出現了網絡阻塞。
是以，第一招，看到接口傳回了所有資料，基本可以預判，這個接口，一定會有網絡瓶頸。
第二招：觀察
執行性能測試，發起方能向被測系統發起請求，那麼就可以斷定，發起方到被測服務之間的網絡一定是通的。這時，我們可以在發起方ping被測伺服器的ip，觀察ping指令的延遲時間。當然，被測伺服器也可能禁ping，導緻ping不通，這時候，你可以使用tracert或traceroute指令，檢視發起方到被測伺服器之間路由節點延遲時間。
一般來說，首先，兩個機器之間網絡連接配接不能丢包。斷斷續續丢包，或持續丢包，那不用說，肯定出現網絡瓶頸了。沒有丢包，再看延遲時長，正常的話，一般在小幾十ms以内，如果出現幾百毫秒甚至更長的延遲，那不用想，肯定出現網絡瓶頸了。
第三招：計算
做性能測試，現在企業用JMeter的比較多，不管你是用GUI圖形界面，還是CLI無圖形界面，都有一個聚合報告或彙總報告可看。
在這個報告的最後兩列，就是網絡吞吐率，機關是KB/s。 這裡看到的數值，是平均網絡吞吐速度。把這兩列中“總體”中最大的值，換算成帶寬的機關Mbps，注意，帶寬機關中的b是小寫，聚合報告中的B是大寫，之間有8倍的關系。換算出來之後，再與你的伺服器的帶寬的比較，如果接近40%～50%，就說明，伺服器帶寬成了瓶頸；不到，那就帶寬沒問題，你的性能資料，可以用于性能分析。
經驗總結的這三招，簡單實用吧！跟着我學，性能測試，不是問題。