作者介紹：Robben，騰訊高級開發(fā)工程師。工作多年，長期從事后臺的開發(fā)、架構(gòu)設(shè)計、優(yōu)化等方面的相關(guān)工作。商業(yè)轉(zhuǎn)載請聯(lián)系騰訊WeTest獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
WeTest導(dǎo)讀
對技術(shù)人員來說，知其然還需知其所以然——搞清技術(shù)的底層機制、弄明白問題的深層次原因、知悉解決方案的適用場景，是每個開發(fā)人員應(yīng)有的技術(shù)素養(yǎng)，也是個人發(fā)展上積累功底、產(chǎn)品生命上維持穩(wěn)定所必須的。
問題背景
8月推送的《當壓測遇見奧運 ——游戲服務(wù)器如何在上線時面對用戶的洪荒之力》中提到了機器人模擬測試是對各類已有的壓力測試方法做了一個平衡， 通過高還原真實玩家的用戶行為，模擬高并發(fā)場景，從而得到類似很多人同時游戲的測試效果。
其中通過模擬機器人測試有四個優(yōu)勢：
1、 高還原游戲玩法，深度模擬真實用戶行為；
2、 并發(fā)性不受限制，從1W到10W，壓力能夠自主設(shè)置；
3、 可以反復(fù)執(zhí)行，便于性能調(diào)優(yōu)回歸；
4、 實現(xiàn)7*24小時不斷監(jiān)控。
在開發(fā)提交代碼之后，版本在自動編譯之后就跑新的測試，這樣每天都能進行性能監(jiān)控，在調(diào)優(yōu)方面，完全的進行一個重復(fù)性測試，可以不斷的進行回歸和調(diào)優(yōu)。這個方法的問題就在于機器人模擬需要專人開發(fā)，對測試者的開發(fā)能力，分析能力都有一個比較高的要求。
而要開發(fā)一款進行服務(wù)器性能測試的機器人，需要通過建模、分析、開發(fā)三個步驟，那么今天我們就要來介紹一下，具體在開發(fā)服務(wù)器性能測試機器人的時候，如何讓它表現(xiàn)的更像人？有更加平穩(wěn)和正常的表現(xiàn)？
為了讓介紹的內(nèi)容更加形象和具有說服力，我從我們自己的產(chǎn)品開始介紹，扒一扒騰訊WeTest服務(wù)器性能測試在開發(fā)機器人的過程中遇到的一些坑。
WeTest平臺的服務(wù)器壓測，支持用戶在一個測試用例中定義遞增的機器人數(shù)量，通過逐步增壓的方式，來探索服務(wù)器的實際承受能力。從下圖的機器人壓力曲線圖可以獲取直觀的概念：
曲線統(tǒng)計的是每個時刻連接到服務(wù)器并且進行業(yè)務(wù)數(shù)據(jù)收發(fā)包的在線機器人個數(shù)，由曲線看上去，可以感受到壓力是平穩(wěn)遞增的（中間有微小下跌，是因為當前的模式下，會在不同的階段更新和重啟機器人，這個也是后面會優(yōu)化之處）。然而，為了在測試結(jié)果報告中畫出這樣一張合理的圖，也是經(jīng)歷了幾番折騰，總結(jié)一下，還是蠻有意思的。
優(yōu)化歷程
對于上圖描述的同一個壓力逐漸遞增的測試用例，經(jīng)過了許多版本的迭代才能得到最終的效果，最早版本的機器人壓力曲線，統(tǒng)計生成后出現(xiàn)了這樣的問題：
【問題】模擬機器人在開始的十幾秒內(nèi)，壓力還算有些頭緒，后面某個時刻，就經(jīng)歷了急劇的下跌，之后就完全無規(guī)律可循了。
【分析】經(jīng)過定位，這個階段的問題是，我們的壓力測試工具在響應(yīng)包較大時，會出現(xiàn)接收緩存區(qū)數(shù)據(jù)被并發(fā)寫入而數(shù)據(jù)污染的情況，導(dǎo)致程序core掉。經(jīng)過快速的修改調(diào)試，問題終于被修復(fù)。OK，壓力曲線應(yīng)該會比較平穩(wěn)了吧。
然而理想很豐滿，現(xiàn)實很骨感，模擬機器人依然存在問題：
【問題】在大概二十秒內(nèi)的時間，還是比較平穩(wěn)地增增減減，維持在一個穩(wěn)定的水平。然后到二十秒后，又會出現(xiàn)急劇地下降，壓力上不去，大概半分鐘后，反撲，上升，沒多久再急劇下降。。。
【分析】首先查看壓力工具的運行邏輯，一切正常；程序，沒core，一切正常；日志錯誤，沒有，一切正常。那壓力為何上不去呢？查看系統(tǒng)的各種運行時數(shù)據(jù)，終于發(fā)現(xiàn)了問題所在：
原因1：由于咱們的機器是部署在合作伙伴騰訊云這里的，機器拿到后也并未進行大的配置調(diào)整，所以系統(tǒng)默認可用的端口范圍還是比較小的，如下圖：
而作為一個模擬機器人的壓力機，必然會在短時間內(nèi)并發(fā)和服務(wù)器建立大量的連接，所以本地的端口號是必須大一點的，直接改文件，增加范圍，搞定：
原因2：其實就是經(jīng)典到有些老生常談的TCP timewait問題了。因為我們壓力機的機器人，會并發(fā)建立很多短連接，并且每次都由機器人主動斷開短連接，所以導(dǎo)致系統(tǒng)中存在大量的timewait連接。直接結(jié)果就是沒法建立新的連接，在線機器人數(shù)量上不去。
這里簡單地提兩個要點：
a) timewait是在TCP連接的主動發(fā)起方才有的狀態(tài)，一句話概況，它是為了防止“主動斷開連接方發(fā)送的最后一個ACK包異常，導(dǎo)致被動關(guān)閉防會重發(fā)FIN請求，影響該四元組上的下一個連接的正確性”這一問題而設(shè)計的，通過主動關(guān)閉方等待2*MSL，即兩倍的報文生存期的時長來避免。如此，報文一來一回的時間都等完了，大概率保證了確實沒異常了。繼而，系統(tǒng)中也就常常會出現(xiàn)大量的timewait連接。
b) 解決的方法，一般是把兩個內(nèi)核參數(shù)：net.ipv4.tcp_tw_recycle、net.ipv4.tcp_tw_reuse都改為1，前者指啟動time wait連接的快速回收，后者指讓time wait的四元組可以快速用于新連接。
然而兩個優(yōu)化都是有需要注意之處的：
對于第一個參數(shù)，當它置1后，為了解決timewait設(shè)計時出發(fā)點的風險，新來的連接請求在如下情況會被拒掉：同一客戶端IP在某時間窗內(nèi)的新連接時間戳變小。雖然一般是不會存在這種情況的，但是，對于NAT而言，則天然容易出現(xiàn)這個問題：A連接服務(wù)器 -->B連接服務(wù)器 --> B 先被accept --> A（同一NAT IP）請求到了服務(wù)器 --> A請求被據(jù)。
對于第二個參數(shù)，一般認為，它不太能解決純服務(wù)端的資源占用問題，因為四元組雖然能用了，但資源還是沒釋放；但對于有客戶端性質(zhì)的情況是適用的，如連接mysql的服務(wù)端php進程。
了解了這些之后，我們的壓力機，既不存在要響應(yīng)NAT過來的客戶端請求的情況，又不存在服務(wù)器端的特點，所以天然是非常適合用這兩個內(nèi)核參數(shù)的優(yōu)化的。
經(jīng)過這一輪系統(tǒng)參數(shù)的優(yōu)化后，在線機器人數(shù)量基本穩(wěn)定了：
因為是短連接，所以在線機器人的數(shù)量曲線并不是水平的，但至少可以一直保持較高的并發(fā)。更進一步，我們在產(chǎn)品的實現(xiàn)層面又做了優(yōu)化，開放長短連接配置給用戶，同時對于HTTP協(xié)議的簡單模式，仿照真實的瀏覽器行為，將默認行為置為長連接。這樣，就會出現(xiàn)文章開頭的理想曲線了：
總結(jié)感受
其實本文中的優(yōu)化只是非常小的一個點，也沒有什么驚心動魄的過程與艱深晦澀的理論，幾輪優(yōu)化著手點涉及的概念范疇也雜，但卻是一個真實的逐步解決問題的典型。
在這個網(wǎng)絡(luò)發(fā)達，信息爆炸的時代，基本上對于每個技術(shù)點或者問題，都可以迅速地獲取到大量資料。關(guān)鍵是對于技術(shù)的實現(xiàn)原理和問題的解決方案，卻不能僅僅知其然，還必須知其所以然——搞清技術(shù)的底層機制、弄明白問題的深層次原因、知悉解決方案的適用場景，是每個開發(fā)人員應(yīng)有的技術(shù)素養(yǎng)，也是個人發(fā)展上積累功底、產(chǎn)品生命上維持穩(wěn)定所必須的。
而騰訊WeTest的壓力測試團隊正是運用了沉淀十多年的內(nèi)部實踐經(jīng)驗總結(jié)，通過基于真實業(yè)務(wù)場景和用戶行為進行壓力測試，推出一套面向游戲業(yè)務(wù)的綜合性應(yīng)用性能管理解決方案，該方案旨在幫助游戲開發(fā)者發(fā)現(xiàn)服務(wù)器端的性能瓶頸，進行針對性的性能調(diào)優(yōu)，降低服務(wù)器采購和維護成本，提高用戶留存和轉(zhuǎn)化率。
目前騰訊WeTest服務(wù)器性能測試已經(jīng)正式對外開放，業(yè)務(wù)場景模擬，持續(xù)壓力觸達服務(wù)器極限，幫助尋找服務(wù)器性能問題！點擊鏈接：http://wetest.qq.com/gaps/立即體驗！
