locust使用經驗---每個任務使用新的鏈接以及處理大量TIME_WAIT連接
最近由於項目需要，在研究打壓測試工具，以及當測試連接過多後端服務器配置問題
測試工具選用locust，locust中文意思為蝗蟲，可以想象，locust就像成片的蝗蟲，撲向我們的服務。
它支持分布式的打壓測試，每個實例可自定義執行任務，執行任務可用python腳本實現，具體如何寫python腳本這裏就不詳細介紹了，網上能搜到很多相關資料，這次的文章主要著重介紹如何實現我們的需求以及對遇到的問題分析。遇到的問題主要是兩個：如何在每次執行任務都使用新的連接，大量連接時如何處理大量出現的TIME_WAIT連接
首先，我的測試場景是，大量的客戶端會間歇性的請求服務器，並不會長時間連接，基本可以理解為每次請求都是短連接，每條連接發起一次請求後就會斷開。所以首先需要解決的問題是，如何使每次執行任務都是用新的連接。
locust默認使用的是requests庫，創建的會話默認會使用長連接，會復用連接，一條發起多次請求，這並不符合我的要求，所以在每次請求完數據後，我需要自己關閉連接。
關閉連接的手段有很多：
a、斷開整個會話的連接 self.client.close() b、斷開客戶端連接 r = self.client.request("post", "/api/query", data=json.dumps(payload), verify=False)r.connection.close() c、請求時帶著Connection: close頭部，讓服務器斷開連接（在HTTP1.1協議中，Connection頭部有兩個值，close和keep-alive，這個頭就相當於客戶端告訴服務端，服務端你執行完成請求之後，是關閉連接還是保持連接，保持連接就意味著在保持連接期間，只能由客戶端主動斷開連接） r = self.client.request("post", "/api/query", headers={‘Connection‘:‘close‘}, data=json.dumps(payload), verify=False) 不論a、b還是c，都能實現每次請求後連接斷開的目的，但是引發的副作用卻不一樣。 因為tcp連接有一種TIME_WAIT狀態，連接的主動關閉方在發送四次揮手的最後一個ACK後會變為TIME_WAIT狀態，保留此狀態的時間為兩個MSL（linux裏一個MSL為30s，是不可配置的）
c方法的FIN報文由服務器發起
如果由服務器斷開連接，會導致服務器端產生大量TIME_WAIT狀態的連接，這個問題直接的影響就是服務器的端口很快會被耗盡，導致客戶端無法與服務器成功建立新的連接
而如果由客戶端斷開連接，經測試，測試機端很快出現上萬的TIME_WAIT狀態的連接，測試量根本打不上去，大量連接建立失敗
所以我們需要調整系統的配置，來優化tcp連接的處理
net.ipv4.tcp_tw_reuse=1 開啟重用，允許將TIME_WAIT重用與新的連接
net.ipv4.tcp_fin_timeout = 30 增大最多允許TIME_WAIT的數量 net.ipv4.tcp_max_tw_buckets = 256000 縮短TIME_WAIT_2到TIME_WAIT的超時時間 sysctl -p 使能新的配置 如果必須由服務器斷開連接，這個問題如何優化？（參考鏈接：https://www.jianshu.com/p/2da62c5e10fa） 1，盡量調大系統TIME_WAIT連接數 net.ipv4.tcp_max_tw_buckets = 256000 最多允許time-wait數量，最大閾值 2，調整TIME_WAIT_2到TIME_WAIT的超時時間，默認是60s，優化到30s：
net.ipv4.tcp_fin_timeout = 30 3，下面再說一些linux裏TIME_WAIT專有的優化參數reuse、recycle，默認都是關閉的，這兩個參數必須在timestamps打開的前提下才能生效使用
註意：對於tw的reuse、recycle其實是違反TCP協議規定的，服務器資源允許、負載不大的條件下，盡量不要打開（副作用大） net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_tw_reuse = 1 機器作為客戶端時起作用，開啟後time_wait在一秒內回收 net.ipv4.tcp_tw_recycle = 0 （建議不要開啟，現在互聯網NAT結構很多，可能直接無法三次握手） 開啟後在3.5*RTO(RTO時間是根據RTT時間計算而來)內回收TIME_WAIT，並60s內同一源ip主機的socket connect請求中的timestamp必須是遞增的，對於服務端，同一個源ip可能會是NAT後很多機器，這些機器timestamp遞增性無可保證，服務器會拒絕非遞增請求連接，直接導致不能三次握手。
經過權衡，最終決定，服務器暫時不開啟副作用較大的tw參數，由客戶端斷開連接，修改客戶機的配置。
修改後測試，16個slave實例，模擬480個用戶壓測查詢接口，客戶端與服務器均不再出現大量TIME_WAIT連接，RPS輕松上3k
服務器硬件配置較低，2核2G內存，不需要打的特別狠，滿足需求即可
locust使用經驗---每個任務使用新的鏈接以及處理大量TIME_WAIT連接