性能測試-網絡調優

最近在作公司項目登陸模塊的性能測試 ，用的工具是jmeter，常常會遇到相似以下問題：
Address already in use: connect
或者：
connect timeout
網上查閱相關資料獲悉windows提供給TCP/IP連接的端口爲 1024-5000，而且要四分鐘來循環回收它們，就致使咱們在短期內跑大量的請求時將端口占滿了，致使如上報錯。這算是性能測試中常見的網絡瓶頸問題

---

在性能測試中，網絡問題，在沒有特別說明的狀況下，通常指的是http協議下的網絡問題，http屬於應用層傳輸協議，用http進行網絡通訊，用的是TCP/UDP進行傳輸。

TCP進行傳輸，有四個組成原件，源地址，源端口，目的地址，目的端口。
源地址：發起通訊的ip（域名）地址
源端口：發起通訊的端口
目的地址：接受通訊的ip（域名）地址
目的端口：接受通訊請求的端口
舉個例子：個人ip:192.168.138.進行受權，登陸；受權模塊對外端口是443，登陸模塊對外端口是9998；受權成功會跳轉到登陸頁面，此時的源地址，目的地址都爲:192.168.138.，原端口是443，目的端口是9998

在性能測試中，高併發場景下會佔用大量的端口，若是這些端口沒有釋放就會出現端口不夠用的狀況

一.源端口不夠用

首先，端口總共有 65535 個，其中
1.0~1023(共 1024 個)，爲公認端口，緊密的綁定在一些特定服務上，如 21 端口就是 FTP 服務，80 端口就是 HTTP 服務，443端口是https服務
2.1024~49151(共 48127 個)，爲註冊端口，鬆散的綁定於一些服務，如 8080 端口經常就用於綁定 Tomcat 服務；
3.49152~65535(共 16384 個)，爲動態或私有端口。

因此在使用windows作性能測試時，最大可以使用的端口16400+,由於註冊端口中有一部分也可用來進行TCP通訊，因此通常可用的動態端口會稍微比16384多一點

---

windows系統TCP鏈接數
netstat -ano | find "TCP" /i /c

netstat:顯示協議 和統計當前TCP/IP連接狀況
-a:顯示全部鏈接數和監聽端口
-n:以數字形式顯示地址和端口號
-o:顯示擁有的與每一個進程數關聯的進程ID

-I:搜索不區分大小寫
-c:對指定信息進行計數，並顯示總計

linux指令查看TCP鏈接數
netstat -ano |grep 'tcp' | wc -l

---

出現 Address already in use: connect 這個問題，緣由不少，但源地址端口不夠用，就是其中一個常見的緣由

可嘗試以下方法進行性能調優
方法一：
若是是使用 jmeter 進行性能測試，出現上述報錯，能夠直接去掉 http 取樣器的 【使用 KeepAlive】 複選勾

方法二：
打開系統的註冊表，找到 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]， 看下右側的配置信息，有沒有 MaxUserPort 配置項
有，則修改值爲 65534(十進制)，肯定
沒有，則新增一個 DWORD, name 爲 MaxUserPort, value 爲 65534(十進制)，肯定
重啓系統
完成這一步，咱們已經知道，咱們的系統當前端口可用範圍已經達到最大。
接下來，咱們還須要知道，端口被使用後，若是咱們能及時回收，再利用是否是能提升端口利用率，這樣是否是就變相增長了端口了呢？

方法三：
打開系統的註冊表，找到 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]， 看下右側的配置信息，有沒有 TcpTimedWaitDe 配置項
有，則修改值爲 10(十進制，10 秒)，肯定
沒有，則新增一個 DWORD, name 爲 TcpTimedWaitDe, value 爲 10(十進制)，肯定
重啓系統

完成這一步，就已經完成了發送方的網絡調優

接下來 就要分析網絡帶寬是否達到瓶頸

二.網絡帶寬瓶頸

通常在性能測試環境準備過程當中，若是條件容許的狀況下，性能測試服務器的網絡帶寬最好時1000Mb/s以上，若是有多個網卡還能夠繼續作bond,這樣就可最大限度的規避網絡傳輸瓶頸。
併發壓測過程當中可經過以下指令來查看服務器端的網絡吞吐，從而肯定是否帶寬成爲瓶頸：

固然客戶端負載機也要確保網絡沒有達到瓶頸：
若是是 Windows10 電腦，能夠在 「網絡鏈接」 > 選中機器網卡，右鍵‘狀態’ > 查看彈窗中的‘速度’

三.目的地址端口瓶頸

壓測過程當中，大量請求來到服務器，最後都是經過某個端口，或者幾個端口真正獲取響應數據。
首先，咱們得知道，一臺機器，再強，也只能接收必定量的請求，這個數量是有最大值的，咱們能夠經過：

若是以爲這個配置的‘max user process' 和 'open files'過小，能夠修改 /etc/security/limits.conf

四.服務內部端口瓶頸

首先咱們能夠查看下當前服務的端口鏈接數量：

這個命令執行完後，你會得到一個數值，這個數量到達必定的峯值以後，就不會再增加了，當你測試結束的時候，這個峯值就會逐步下降若是前面三項都沒問題狀況下，網絡瓶頸一直上不去，可嘗試此方法，來檢查對應的模塊服務內部是否是可以處理的連接請求書已經達到瓶頸