网站性能压力测试是服务器网站性能调优过程中必不可缺少的一环。只有让服务器处在高压情况下，才能真正体现出软件、硬件等各种设置不当所暴露出的问题
ab是apache自带的压力测试工具。ab非常实用，它不仅可以对apache服务器进行网站访问压力测试，也可以对或其它类型的服务器进行压力测试。比如nginx、tomcat、IIS等。
一、ab的原理
ab是apache bench命令的缩写。
ab的原理：ab命令会创建多个并发访问线程，模拟多个访问者同时对某一URL地址进行访问。它的测试目标是基于URL的，因此，它既可以用来测试apache的负载压力，也可以测试nginx、lighthttp、tomcat、IIS等其它Web服务器的压力。
ab命令对发出负载的计算机要求很低，它既不会占用很高CPU，也不会占用很多内存。但却会给目标服务器造成巨大的负载，其原理类似CC攻击。自己测试使用也需要注意，否则一次上太多的负载。可能造成目标服务器资源耗完，严重时甚至导致死机
注：CC攻击(ChallengeCoHapsar，挑战黑洞)是DDoS攻击的一种常见类型，攻击者控制某些主机不停地发送大量数据包给对方服务器造成服务器资源耗尽，一直到宕机崩溃。CC攻击主要针对WEB服务器发送大量并发请求，重点针对应用程序中比较消耗资源的功能，占用大量系统资源。CC攻击的攻击技术含量和成本很低， 只要有上百个IP，每个IP弄几个进程，就可以有上千个并发请求，很容易让被攻击目标服务器资源耗尽，从而造成网站宕机。
如果不想安装apache但是又想使用ab命令的话，我们可以直接安装apache的工具包httpd-tools。如下：
yum -y install httpd-tools（在linux环境下）
如果ab安装成功，通过ab –V命令则会显示ab的相应版本
对百度进行模拟100个用户请求1000次，看完成时间以及QPS值
命令如下：ab -n 1000 -c 100 https://www.baidu.com/
参数解释
Server Software: BWS/1.1 //被测试的服务器所用的软件信息，这里使用的是百度自己开发的反向代理Baidu Front End,类似nginx。
Server Hostname: www.baidu.com //被测主机名
Server Port: 443 //被测主机的服务端口号，一般http请求的默认端口号是80，https默认使用443端口
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128 //加密协议
Document Path: /index.html//请求的具体文件(本次请求的是根目录)
Document Length: 227 bytes //请求的文件index.html大小
Concurrency Level: 100 //并发级别，也就是并发数，请求中－c参数指定的数量
Time taken for tests: 3.781 seconds //本次测试总共花费的时间
Complete requests: 1000 //本次测试总共发起的请求数量
Failed requests: 0 //失败的请求数量。因网络原因或服务器性能原因，发起的请求并不一定全部成功，通过该数值和Complete requests相除可以计算请求的失败率，作为测试结果的重要参考。
Total transferred: 1081868 bytes//总共传输的数据量，指的是ab从被测服务器接收到的总数据量，包括index.html的文本内容和请求头信息。
HTML transferred: 22700 bytes //从服务器接收到的index.html文件的总大小，等于Document Length＊Complete requests＝227 bytes＊100＝22700 bytes
Requests per second: 264.50 [#/sec](mean) //平均(mean)每秒完成的请求数：QPS，这是一个平均值，等于Complete requests/Time taken fortests=1000/3.781= 264.50
Time per request: 378.068 [ms] (mean) //从用户角度看，完成一个请求所需要的时间（因用户数量不止一个，服务器完成100个请求，平均每个用户才接收到一个完整的返回，所以该值是下一项数值的10倍。）
Time per request: 3.781 [ms] (mean, across all concurrent requests)// 服务器完成一个请求的时间。
Transfer rate: 279.45 [Kbytes/sec] received//网络传输速度。对于大文件的请求测试，这个值很容易成为系统瓶颈所在。要确定该值是不是瓶颈，需要了解客户端和被测服务器之间的网络情况，包括网络带宽和网卡速度等信息。
Connection Times (ms)
min mean [+/-sd] median max
Connect: 113 264 38.0 268 358
Processing: 41 89 13.4 90 181
Waiting: 35 89 13.4 90 180
Total: 155 353 48.9 363 474
//这几行组成的表格主要是针对响应时间也就是第一个Time per
request进行细分和统计。一个请求的响应时间可以分成网络链接（Connect），系统处理（Processing）和等待（Waiting）三个部分。表中min表示最小值； mean表示平均值；[+/-sd]表示标准差（StandardDeviation） ，也称均方差（mean squareerror），这个概念在中学的数学课上学过，表示数据的离散程度，数值越大表示数据越分散，系统响应时间越不稳定。 median表示中位数；max当然就是表示最大值了。
//需要注意的是表中的Total并不等于前三行数据相加，因为前三行的数据并不是在同一个请求中采集到的，可能某个请求的网络延迟最短，但是系统处理时间又是最长的呢。所以Total是从整个请求所需要的时间的角度来统计的。这里可以看到最慢的一个请求花费了474ms，这个数据可以在下面的表中得到验证。
Percentage of the requests served within a certain time (ms)
50% 363
66% 380
75% 392
80% 400
90% 410
95% 414
98% 420
99% 426
100% 474 (longest request)
//这个表第一行表示有50%的请求都是在363ms内完成的，可以看到这个值是比较接近平均系统响应时间（第一个Time per request: 378.068 [ms] (mean) ）
以此类推，90%的请求是小于等于410ms的。刚才我们看到响应时间最长的那个请求是474ms，那么显然所有请求（100%）的时间都是小于等于474毫秒的，也就是表中最后一行的数据肯定是时间最长的那个请求（longest request）。