Apache Benchmark安装、参数含义&使用总结、结果分析

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/sangyongjia/article/details/49093945

首先,介绍下背景,我使用的系统是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 過高),但這只是建議,你也可以一下子操死你的主機,反正你在測主機的極限嘛!

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试

关闭