.Net網站架構時間(八)測試
工具是采用用.NET編寫,所以需要.NET FRAMEWORK才能運行.雖然.net在這方面的給人的感覺性能不怎么出色,但這個工作出色性能足夠滿足大部分服務端的壓力測試.
工具非常簡單易用,只需要設置幾項內容就可以對於個服務端進行壓測.在這里比較注意的就是測試模式這里,工具主要提供兩種測試模式分別是
應答模式:當連接接收服務端響應后馬上進行下一次請求消息發送
間隔模式:連接根據設置的間隔時間來進行發送請求消息
在發起測試之前還需要給工作添加測試消息,明確工具向服務器發送那些消息內容
可以根據自己的需要編輯多發送的消息,每個連接都會輪遁把這些消息發送給服務端,消息的編碼也可以根據自己需要設置.工具提供4種分別是:ascii,utf8,hex和base64.
當以上工作都准備好后就可以點擊測試按鈕進行測試,工具下方的幾個曲線走勢圖會反映測試過程數據收集的結果.通過這些結果你就能了解到服務端響應的情況和整體吞吐瀏覽走勢.
工具到底具備怎樣的壓力效能呢,下面通過兩個測試用例反映工具具備的測試能力.
構建一個簡單的TCP服務,然后在另一台機構建5000個連接的請求測試(測試電腦是一台筆記本),請求消息大小為1K;測試結果如下:
從結果來看5000個連接請求測試結果反映出整體交互是每秒6W個發送和6W個接收,而產生帶寬上下行分別是60MB,那基本已經把測試環境1Gb的帶寬跑完了.從系統的資源管理器來看的確是這樣子.
這個測試主要把發送的消息設置成4K,由於網絡環境所以只能把測試工具和服務端放在同一台PC上.而測試的連接數降到的2000個
測試結果反映socket的讀寫量分別是4W左右,而上下行的帶寬分別170MB左右,算起來大概帶寬達到3-4Gb之間.
組件也可以對HTTP進行測試,由於測試工具是基於長連接測試,所以請求描述必須用HTTP 1.1,並設置keep-alive;具體消息設置如下:
從以上兩個測試用例的結果反映,工具具備着非常不錯的壓力測試效率.相信對於大部分TCP/UDP服務壓力測試工作都能勝任.由於工作采用的隨機端口分配,所以在創建連接的數量上會有一定的限制,后面會調整一下根據本機IP情況過行手動綁定,這樣相信可以滿足一些需大量連接服務測試.
http://blog.liuts.com/post/234/本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。