如何讓壓力測試產生平穩的機器人曲線——壓測后臺的一次優化歷程

作者介紹:Robben,騰訊高級開發工程師。工作多年,長期從事后臺的開發、架構設計、優化等方面的相關工作。商業轉載請聯系騰訊WeTest獲得授權,非商業轉載請注明出處。

WeTest導讀

對技術人員來說,知其然還需知其所以然——搞清技術的底層機制、弄明白問題的深層次原因、知悉解決方案的適用場景,是每個開發人員應有的技術素養,也是個人發展上積累功底、產品生命上維持穩定所必須的。

問題背景

8月推送的《當壓測遇見奧運 ——游戲服務器如何在上線時面對用戶的洪荒之力》中提到了機器人模擬測試是對各類已有的壓力測試方法做了一個平衡, 通過高還原真實玩家的用戶行為,模擬高并發場景,從而得到類似很多人同時游戲的測試效果。
其中通過模擬機器人測試有四個優勢:
1、 高還原游戲玩法,深度模擬真實用戶行為;
2、 并發性不受限制,從1W到10W,壓力能夠自主設置;
3、 可以反復執行,便于性能調優回歸;
4、 實現7*24小時不斷監控。
在開發提交代碼之后,版本在自動編譯之后就跑新的測試,這樣每天都能進行性能監控,在調優方面,完全的進行一個重復性測試,可以不斷的進行回歸和調優。這個方法的問題就在于機器人模擬需要專人開發,對測試者的開發能力,分析能力都有一個比較高的要求。

而要開發一款進行服務器性能測試的機器人,需要通過建模、分析、開發三個步驟,那么今天我們就要來介紹一下,具體在開發服務器性能測試機器人的時候,如何讓它表現的更像人?有更加平穩和正常的表現?

為了讓介紹的內容更加形象和具有說服力,我從我們自己的產品開始介紹,扒一扒騰訊WeTest服務器性能測試在開發機器人的過程中遇到的一些坑。

WeTest平臺的服務器壓測,支持用戶在一個測試用例中定義遞增的機器人數量,通過逐步增壓的方式,來探索服務器的實際承受能力。從下圖的機器人壓力曲線圖可以獲取直觀的概念:

曲線統計的是每個時刻連接到服務器并且進行業務數據收發包的在線機器人個數,由曲線看上去,可以感受到壓力是平穩遞增的(中間有微小下跌,是因為當前的模式下,會在不同的階段更新和重啟機器人,這個也是后面會優化之處)。然而,為了在測試結果報告中畫出這樣一張合理的圖,也是經歷了幾番折騰,總結一下,還是蠻有意思的。

優化歷程

對于上圖描述的同一個壓力逐漸遞增的測試用例,經過了許多版本的迭代才能得到最終的效果,最早版本的機器人壓力曲線,統計生成后出現了這樣的問題:

【問題】模擬機器人在開始的十幾秒內,壓力還算有些頭緒,后面某個時刻,就經歷了急劇的下跌,之后就完全無規律可循了。

【分析】經過定位,這個階段的問題是,我們的壓力測試工具在響應包較大時,會出現接收緩存區數據被并發寫入而數據污染的情況,導致程序core掉。經過快速的修改調試,問題終于被修復。OK,壓力曲線應該會比較平穩了吧。

然而理想很豐滿,現實很骨感,模擬機器人依然存在問題:
【問題】在大概二十秒內的時間,還是比較平穩地增增減減,維持在一個穩定的水平。然后到二十秒后,又會出現急劇地下降,壓力上不去,大概半分鐘后,反撲,上升,沒多久再急劇下降。。。

【分析】首先查看壓力工具的運行邏輯,一切正常;程序,沒core,一切正常;日志錯誤,沒有,一切正常。那壓力為何上不去呢?查看系統的各種運行時數據,終于發現了問題所在:

原因1:由于咱們的機器是部署在合作伙伴騰訊云這里的,機器拿到后也并未進行大的配置調整,所以系統默認可用的端口范圍還是比較小的,如下圖:

而作為一個模擬機器人的壓力機,必然會在短時間內并發和服務器建立大量的連接,所以本地的端口號是必須大一點的,直接改文件,增加范圍,搞定:

原因2:其實就是經典到有些老生常談的TCP timewait問題了。因為我們壓力機的機器人,會并發建立很多短連接,并且每次都由機器人主動斷開短連接,所以導致系統中存在大量的timewait連接。直接結果就是沒法建立新的連接,在線機器人數量上不去。

這里簡單地提兩個要點:
a) timewait是在TCP連接的主動發起方才有的狀態,一句話概況,它是為了防止“主動斷開連接方發送的最后一個ACK包異常,導致被動關閉防會重發FIN請求,影響該四元組上的下一個連接的正確性”這一問題而設計的,通過主動關閉方等待2*MSL,即兩倍的報文生存期的時長來避免。如此,報文一來一回的時間都等完了,大概率保證了確實沒異常了。繼而,系統中也就常常會出現大量的timewait連接。

b) 解決的方法,一般是把兩個內核參數:net.ipv4.tcp_tw_recycle、net.ipv4.tcp_tw_reuse都改為1,前者指啟動time wait連接的快速回收,后者指讓time wait的四元組可以快速用于新連接。
然而兩個優化都是有需要注意之處的:
對于第一個參數,當它置1后,為了解決timewait設計時出發點的風險,新來的連接請求在如下情況會被拒掉:同一客戶端IP在某時間窗內的新連接時間戳變小。雖然一般是不會存在這種情況的,但是,對于NAT而言,則天然容易出現這個問題:A連接服務器 -->B連接服務器 --> B 先被accept --> A(同一NAT IP)請求到了服務器 --> A請求被據。
對于第二個參數,一般認為,它不太能解決純服務端的資源占用問題,因為四元組雖然能用了,但資源還是沒釋放;但對于有客戶端性質的情況是適用的,如連接mysql的服務端php進程。
了解了這些之后,我們的壓力機,既不存在要響應NAT過來的客戶端請求的情況,又不存在服務器端的特點,所以天然是非常適合用這兩個內核參數的優化的。
經過這一輪系統參數的優化后,在線機器人數量基本穩定了:

因為是短連接,所以在線機器人的數量曲線并不是水平的,但至少可以一直保持較高的并發。更進一步,我們在產品的實現層面又做了優化,開放長短連接配置給用戶,同時對于HTTP協議的簡單模式,仿照真實的瀏覽器行為,將默認行為置為長連接。這樣,就會出現文章開頭的理想曲線了:

總結感受

其實本文中的優化只是非常小的一個點,也沒有什么驚心動魄的過程與艱深晦澀的理論,幾輪優化著手點涉及的概念范疇也雜,但卻是一個真實的逐步解決問題的典型。
在這個網絡發達,信息爆炸的時代,基本上對于每個技術點或者問題,都可以迅速地獲取到大量資料。關鍵是對于技術的實現原理和問題的解決方案,卻不能僅僅知其然,還必須知其所以然——搞清技術的底層機制、弄明白問題的深層次原因、知悉解決方案的適用場景,是每個開發人員應有的技術素養,也是個人發展上積累功底、產品生命上維持穩定所必須的。

而騰訊WeTest的壓力測試團隊正是運用了沉淀十多年的內部實踐經驗總結,通過基于真實業務場景和用戶行為進行壓力測試,推出一套面向游戲業務的綜合性應用性能管理解決方案,該方案旨在幫助游戲開發者發現服務器端的性能瓶頸,進行針對性的性能調優,降低服務器采購和維護成本,提高用戶留存和轉化率。

目前騰訊WeTest服務器性能測試已經正式對外開放,業務場景模擬,持續壓力觸達服務器極限,幫助尋找服務器性能問題!點擊鏈接:http://wetest.qq.com/gaps/立即體驗!

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容