首先,介绍下背景,我使用的系统是CentOS7.1。
Apache Benchmark简称AB,安装有两种方式:
1.使用sudo yum install httpd-tools 命令安装(比较简单便捷,我使用的是此种方式)。
2.下载Apache的源码,编译安装(感兴趣的可以试试这种方式)。
参数含义&使用总结:
本节内容大多源引自:http://blog.miniasp.com/post/2008/06/30/Using-ApacheBench-ab-to-to-Web-stress-test.aspx
经常使用的参数如下:
1.同时10个连线,连续点击10000(每个Request执行完成后都会自动断线,然后再重新连线)(疑问:每次等10个都返回结果了,在同时发起10个访问?)
2.同时10个连线,连续点击10000,并且使用Keep-Alive方式连线(当Web Server支持Keep-Alive功能时Apache Benchmark会在同一个连线下连续点击该网页)
注:根据我的使用经验,发现使用-k参数后,系统的QPS就会急剧的下降,不知道是哪些地方设置有问题还是怎么回事儿?
3.将测试中的某些数据输出到output.csv文件中
注:参数-e和-g均会生成一个数据文件,但内部的数据的含义,以及有什么价值,现在还体会不到。
4.参数-r很有必要说下,在我使用ab时发现-n 不超过5000的情况下,-c可以任意设置(小于-n的参数即可)都没有问题,但是当-n的参数设置大于5000,同时-c参数大于200时总是返回如下图的错误:(注:以上数据只是个约数,但通常在这些数字附近就会出现错误)
针对这个问题,网上的解决办法基本一致,但我试了以后还是不能解决我的问题(注:解决办法参见转载的这篇文章)。
最后发现使用参数-r即可解决这个问题,但是如下图中的Failed requests就会有很多。(注:此图只是说明,并不是高并发,大访问量情况下使用-r参数真实结果)
关于Failed requests这个参数即括号中四个参数的解释,可参见网页:http://blog.miniasp.com/post/2009/10/07/Explain-ApacheBench-ab-for-the-Failed-request-field.aspx
5.设定测试时间
此例的含义为:并发访问数为3,持续访问时间为5分钟(300秒)
结果分析:
压力测试的核心在于:在可靠的数据的前提下进行结果分析。下面结合一次测试的结果来说明每个结果数据所代表的意义。其中相比较更重要的数据项为:
Failed requests、Requests per second和Time per request。其中Failed Requests的数量太高的话,很有可能代表你的Web Application的稳定度不够,而导致大量请求无法响应;Request per second代表每秒可以处理的请求数,即代表Web Application的承载量有多少(在不考虑带宽限制的情况下)。
例子如下:
下面具体解释下各个参数的含义:
- Server Software: Web主機的作業系統與版本(若Web主機設定關閉此資訊則無);在此例中就是压力测试的对象nginx
- Server Hostname: Web主機的IP位址(Hostname)
- Server Port: Web主機的連接埠(Port)
- Document Path: 測試網址的路徑部分
- Document Length: 測試網頁回應的網頁大小
- Concurrency Level: 同時進行壓力測試的人數
- Time taken for tests: 本次壓力測試所花費的總秒數 ;此次压力测试花费的世间
- Complete requests: 完成的要求數(Requests)
- Failed requests: 失敗的要求數(Requests)
- Write errors: 寫入失敗的數量
- Total transferred: 本次壓力測試的總數據傳輸量(包括 HTTP Header 的資料也計算在內)
- HTML transferred: 本次壓力測試的總數據傳輸量(僅計算回傳的 HTML 的資料)
- Requests per second: 平均每秒可回應多少要求 ;是否可以认为是QPS
- Time per request: 平均每個要求所花費的時間(單位: 豪秒) ;每次并发请求时间(所有并发)
- Time per request: 平均每個要求所花費的時間,跨所有同時連線數的平均值(單位: 豪秒) ;每一次请求时间(并发平均)
- Transfer rate: 從 ab 到 Web Server 之間的網路傳輸速度
最後的 Connection Times (ms) 指的是壓力測試時的連線處理時間:
橫軸欄位的部分:
- min: 最小值
- mean: 平均值(正、負標準差)
- median: 平均值(中間值)
- max: 最大值
縱軸欄位的部分:
- Connect: 從 ab 發出 TCP 要求到 Web 主機所花費的建立時間。
- Processing: 從 TCP 連線建立後,直到 HTTP 回應(Response)的資料全部都收到所花的時間。
- Waiting: 從發送 HTTP 要求完後,到 HTTP 回應(Response)第一個 Byte 所等待的時間。
- Total: 等於 Connect + Processing 的時間(因為 Waiting 包含在 Processing 時間內了)
壓力測試的基本觀念
- 排除頻寬的限制
- 做壓力測試通常不會考量「頻寬的限制」,所以一般來說不會將測試的主機擺在遠端機房、然後測試程式擺在公司內部的主機,而是會將壓力測試的 Client 跟 Web 主機擺在同一個網段下進行壓力測試。
- 因為「頻寬」只要花錢就會有了,但是主機的承載量卻是有限的,從遠端進行壓力測試主要的限制是在「頻寬」而非「效能」,所以從遠端單點進行壓力測試毫無任何意義可言,這樣是測不出主機的效能極限的。
- 如果你有能力與資源進行大規模(多點)壓力測試的話,透過遠端進行壓力測試才有意義。
- 壓力要循序漸進
- 你不要一下字就執行同時連線數 100 人,而是要循序漸進的慢慢加同時連線數上去,才不會讓 Web Application 一下字承受過大的負載而導致效能的數據不正確(例如說 Failed requests 過高),但這只是建議,你也可以一下子操死你的主機,反正你在測主機的極限嘛!