這兩天因為要對剛上線的專案進行壓力測試，比較緊急，使用了不怎麼熟悉的Jmeter。雖然之前用過一段時間LoadRunner，但是由於它本身過於沉重，安裝比較複雜，對加壓機和被加壓機要求比較高，而且本人在linux上面沒有使用經驗。更重要的是它是收費的，需要相當昂貴的價格購買license，於是放棄它而選擇了更為輕量的Jmeter。
在原理上Jmeter和LoadRunner其實都是一樣的，通過指令碼程式碼模擬多使用者向伺服器發請求。
上手是很快，但是出問題的話就頭疼了。本來在WIN7圖形介面建立測試計劃，寫好程式碼跑了幾次都沒什麼問題。
但是部署到伺服器上就麻煩多了，最大的問題就是必須用命令跑指令碼，跑出的結果要先dump到檔案，然後下載到win7上，再用Jmeter開啟才能看分析結果。有的時候由於資料載入到記憶體膨脹， 經常OOM-_-。
雖然經過了幾番掙扎，也算是摸清了命令列執行的流程。但是就在跑真實資料的時候，日誌中一直報超時的異常。

• 用ping命令和telnet命令，可以確認伺服器埠是可以訪問到的
• 介面有鑑權判斷。查程式碼看日誌問開發人員，排除了這個可能
• 查日誌，打log，發現數據庫確實返回了正確的資料，這就排除資料庫訪問超時的可能
• 由於不是正式上線，沒有做DDos之類的攔截，排除了被系統限制的可能

到這裡，問題還是沒有解決，已經開始心灰意冷，整個人都不好了。最最可恥的是調錯誤的API可以返回錯誤提示，但是訪問正確的API就超時，這個問題也太離譜了。
最後只能一點點排查指令碼的問題。換了N多個介面，檢查了N多次Host設定和介面路徑。改一點測一次。最後當去掉斷言的時候，超時的異常突然消失了-_-.. 測試計劃竟然通了。後來反覆測試，終於意識到Jmeter在命令列模式下執行斷言時，如果斷言結果為true，就會一直報超時。
目前還不知道什麼原因，被誤導浪費了兩天時間也太慘了。