測試系統：公司網站的beta環境，本次測試數據有大約9萬條數據。系統的架構為lamp+nginx，數據的流向，從mysql數據庫 做一個dumper 每10分鐘dump一次數據到系統的引擎。引擎是提供給用戶垂直搜索的數據集合。
測試數據來源：收集線上訪問的日志，并做相關的參數化。
測試步驟：
1.準備相關測試工具，這里采用http_load ，測試命令sudo http_load -f 1000 -p 10 url.txt
2.準備測數據，目前該工具只支持get的請求，收集引擎服務器上的訪問log 作為url，注意收集的 url 非常重要 他關系這個本次測試是否有效 ，最好收集 線上服務器的一個小時內的訪問log 做修改和參數化
3.新舊版本對比測試，跑數據 -f 1000 -p 10 ; -f 2000 -p 20 ; -f 3000 -p 30; -f 5000 -p 50 ;-f 10000 -p 100 .每組數據跑三次 取平均的結果，當然跑多次取平均最好。
2000 fetches, 20 max parallel, 9.63347e+07 bytes, in 89.0738 seconds 48167.3 mean bytes/connection 22.4533 fetches/sec, 1.08152e+06 bytes/sec msecs/connect: 0.250249 mean, 0.763 max, 0 min msecs/first-response: 874.104 mean, 4883.77 max, 3.489 min 33 bad byte counts HTTP response codes: code 200 -- 1952 code 400 -- 1 code 500 -- 47 |
4.結果分析：
22.4533 fetches/sec --這個是qps 業務處理能力
HTTP response codes --這個是記錄訪問成功和失敗的url數據
一般來說 同樣的壓力下 ，qps越高，代表業務處理能力越好性能越好，返回200 越多越好，如果qps相同 但是404，或者5000比較多，就要考慮是不是系統有性能瓶頸
5.補充 ：一般好要監控 服務的性能指標load數和cpu等等，僅僅看返回結果是不準確的，要把這些因素綜合考慮，并且當并發和請求數太多客戶機的性能也要考慮進去