二、ab工具使用
格式： ab [options] [http://]hostname[:port]/path
例如：ab -n 1000 -c 10 https://
引數：//
在測試會話中所執行的請求個數。預設時，僅執行乙個請求
-n requests number of requests to perform
//一次產生的請求個數。預設是一次乙個。
//apache版本資訊
//平台bws 版本1.1
server software: bws/1.1
//請求ip或者網域名稱
//請求埠，當前請求為https所以埠為443，請求https埠80
server port: 443
//https埠協議
//路徑
document path: /
//第乙個成功返回的文件的位元組大小
document length: 227
bytes
//併發數！！！
concurrency level: 10
//從建立連線到最後接受完成總時間
time taken for tests: 17.851
seconds
//總請求數成功的
complete requests: 1000
//失敗的
failed requests: 0
//從伺服器接收的位元組總數
total transferred: 893000
bytes
//html接收位元組數
html transferred: 227000
bytes
//核心引數1:吞吐率，指某個併發使用者數下單位時間內處理的請求數；
requests per second: 56.02 [#/sec] (mean)
//核心引數2:是使用者平均請求等待時間，指處理完成所有請求數所花費的時間 /（總請求數 / 併發使用者數）；time per request: 178.515
[ms] (mean)
//是伺服器平均請求處理時間，指處理完成所有請求數所花費的時間 / 總請求數；
time per request: 17.851
[ms] (mean, across all concurrent requests)
//平均每秒網路上的流量，可以幫助排除是否存在網路流量過大導致響應時間延長的問題
transfer rate: 48.85 [kbytes/sec] received
//網路上消耗的時間的分解，各項資料的具體演算法還不是很清楚
connection times (ms)
min mean[+/-sd] median max
connect:
43139
33.0
138316
processing: 738
39.1
321023
waiting: 629
38.5
211023
total:
55177
48.4
1741137
//每秒請求時間分布情況，指在整個請求中，每個請求的時間長度的分布情況，下
面每個請求都有乙個響應時間，其中50％的使用者響應時間小於174 毫秒，
80％ 的使用者響應時間小於203 毫秒，最大的響應時間小於1137 毫秒
由於對於併發請求，cpu實際上並不是同時處理的，而是按照每個請求獲得的時間片逐個輪轉處理的，
所以基本上第乙個time per request時間約等於第二個time per request時間乘以併發請求數
percentage of the requests served within a certain time (ms)
50% 174
66% 188
75% 198
80% 203
90% 224
95% 244
98% 270
99% 289
100% 1137 (longest request)
效能測試 效能測試步驟
針對此次庫內作業效能測試，梳理一下期間的工作流程 梳理已有的介面指令碼，確認需要做效能測試的幾個介面，即使用率高，對效能有要求的幾個主要介面。結合頁面的操作，和確認的介面，梳理具體的業務邏輯 同時，請開發人員部署了測試環境。測試環境的伺服器指標，盡量和生產環境一致。部署的時候，負載均衡等情況也盡量和...
效能測試之前端效能測試
本次總結總共分為以下部分 1.如何衡量乙個系統是否要做壓測 2.壓測的準備過程 3.壓測工具選擇 4.壓測資料以及報告結果相關 1.如何衡量乙個系統是否要做壓測 首先需要衡量乙個系統是否需要壓測，從以下角度考慮 從兩個角度進行分析 a.業務角度 明確系統是對內使用還是對外使用，使用人數是多少，如果使...
IT之路 效能測試系列 初識效能測試
上一章節我們大概了解了下loadrunner，這一章，我們來認識一下效能測試。說到效能測試，很多同學會有自己不同的感想。web前端的測試同學說 頁面怎麼半天打不開啊，沒辦法測啊，必須改善。一線運維的同學說 靠，系統上線這才多久啊，怎麼就嘎嘣的宕機了？這可以不行啊，客戶跳起來了，必須趕緊處理。終端使用...