首先，介绍下背景，我使用的系统是CentOS7.1。
Apache Benchmark简称AB，安装有两种方式：
1.使用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 過高），但這只是建議，你也可以一下子操死你的主機，反正你在測主機的極限嘛！
如果你是一位站长，随着自己苦心经营的网站越来越受欢迎，网站的流量与日俱增，那么，你是否了解自己的网站，最大能承受多少个用户同一时间对网站进行访问？如果网站长时间无法响应，或是响应速度太慢，这会导致有很多的抱怨接踵而至，比如：
1）春运时期，网上订购火车票的12306网站，只要一到放票的瞬间，服务器立马会超负荷的运行，经常会发生响应慢的情况，或者直接死给你看！
2）小米官网的抢购活动，一到12点开抢时间，小米服务器立刻进入崩溃的边缘，现象跟12306差不多。
题外话，现在小米官网针对抢购活动做了些调整，现在的抢购规则已经不是谁第一个点开网页，就能最先进入选购页面，现在添加了一个排队机制，其实就类似于摇号的过程，也可以理解为下边的抛骰子游戏：
a.如果抛不到六点->等待10秒钟，然后重新抛
b.如果此时手机售罄->程序会让你发扬愚公精神，一直重抛->直到过了十几分钟服务器更新缓存，才会给你提示手机售罄，此时活动结束，坑爹吧？
c.如果抛到六点->进入选购界面->如果此时手机售罄->提示对不起，没有库存了
d.如果抛到六点->进入选购界面->如果此时仍有库存->提示抢购成功
小米官网通过类似上边的处理机制，可以很大程度的缓解抢购狂潮对服务器造成的压力。
言归正传，无论什么情况，只要影响到用户的正常使用，都会让用户抱怨，严重的甚至会大量流失用户群,这很残酷，但很现实。
也许你认为现在还不是考虑这个问题的时候，但这是不可避免的，除非你有意向转行不干了。
那么，有没有什么方法能测试出，当有50、100或者更多的用户并发的访问网站的时候，自己的PHP程序会有怎么样的表现？
接下来就来介绍一个实用开源的网站压力测试工具，Apache Benchmark，简称ab。
下边介绍ab最简单的使用方法ab www.baidu.com/
上边的数据中，HTML transferred，Requests persecond，Time perrequest是我们需要重点关注的，根据这些数据，我们能大概了解Web服务器的性能水平。
接下来给出相关字段说明：
Server Software | 服务器系统 |
Server Hostname | 服务器域名 |
Server Port | 服务器端口 |
Document Path | 访问的路径 |
Document Length | 访问的文件大小 |
Concurrency Level | 并发请求数，可以理解为同一时间的访问人数 |
Timetaken fortests | 响应时间 |
Complete requests | 总共响应次数 |
Failed requests | 失败的请求次数 |
Write errors | 失败的写入次数 |
Total transferred | 传输的总数据量 |
HTML transferred | HTML页面大小 |
Requests per second | 每秒支持多少人访问 |
Time per request | 满足一个请求花费的总时间 |
Time per request | 满足所有并发请求中的一个请求花费的总时间 |
Transfer rate | 平均每秒收到的字节 |
最后的数据包括Connect,Processing,Waiting,Total字段。这些数据能大致说明测试过程中所需要的时间。其实我们可以只看Total字段中的min，max两列数据值，这两个值分别显示了测试过程中，花费时间最短和最长的时间。
ab命令还有很多可选参数，但常用的其实就下边三个：参数
| 功能解释 | |
| -n | 设置ab命令模拟请求的总次数 |
| -c | 设置ab命令模拟请求的并发数 |
| -t | 设置ab命令模拟请求的时间 |
| -k | 设置ab命令允许1个http会话响应多个请求 |
这三个参数的用法如下：
1）使用ab命令加上“-n”参数模拟1个用户访问百度总共5次
ab -n 5 www.baidu.com/
2）使用ab命令加上“-n”与“-c”参数模拟5个用户同时访问百度总共9次
ab -c 5 -n 9 www.baidu.com/
使用ab命令加上“-c”与“-t”参数模拟5个用户同时访问百度总共9秒
ab -c 5 -t 9 www.baidu.com/
使用ab命令加上“-c”与“-t”附加“-k”参数模拟5个用户同时访问百度总共9秒,百度会打开5个并发连接，从而减少web服务器创建新链接所花费的时间。
ab -c 5 -t 9 -k www.baidu.com/
使用ab命令的时候，有几点点要说明：
1）ab命令必须指定要访问的文件，如果没指定，那必须得在域名的结尾加上一个反斜杠，例如
ab www.baidu.com
得改写为
ab www.baidu.com/
2）ab命令可能会由于目标web服务器做了相应的过滤处理，导致在某些情况下收不到任何数据，这个时候可以使用“-H”参数，来模拟成浏览器发送请求。例如：
模拟成Chrome浏览器向百度发送1个请求
ab -H
"Mozilla/5.0(Windows; U; Windows NT 5.1; en-Us) AppleWeb Kit/534.2 (KHTML, likeGecko) Chr
最后，要注意的就是，在使用ab命令测试服务器时，千万要小心，并且要限制对服务器发出的请求数量， 磨途歌希望大家理性使用这些压力测试工具，我们都不希望任何一台正常的服务器陷入不必要的麻烦。
更多的可选参数如下：
-A| 采用base64编码向服务器提供身份验证信息，用法: -A 用户名:密码 | |||||||
| -C | cookie信息，用法: -C mo2g=磨途歌 | ||||||
| -d | 不显示pecentiles served table | ||||||
| -e | 保存基准测试结果为csv格式的文件 | ||||||
| -g | 保存基准测试结果为gunplot或TSV格式的文件 | ||||||
| -h | 显示ab可选参数列表 | ||||||
| -H | 采用字段值的方式发送头信息和请求 | ||||||
| -i | 发送HEAD请求，默认发送GET请求 | ||||||
| -p | 通过POST发送数据，用法： -p blog=博客&mo2g=磨途歌 | ||||||
| -P | 采用base64编码向服务器提供身份验证信息，用法: -A 用户名:密码 | ||||||
| -q | 执行多余100个请求时隐藏掉进度输出 | ||||||
| -s | 使用Https协议发送请求，默认使用Http | ||||||
| -S | 隐藏中位数和标准偏差值 | ||||||
| -v | -v 2 及以上将打印警告和信息，-v 3 打印http响应码，-v 4 打印头信息 | ||||||
| -V | 显示ab工具的版本号 | ||||||
| -w | 采用HTML表格打印结果 | ||||||
| -x | HTML标签属性，使用 -w 参数时，将放置在标签中标签中
|
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
