apache bench

ab是apache下的一个工具，主要用于对web站点做压力测试。

安装

1、centos

yum install httpd-tools

使用

ab [可选的参数] 需要进行压力测试的url

-n
用于指定压力测试总共执行的次数
-c
指定并发数
-t
等待响应的最大时间
-b
TCP发送和接收的缓冲大小（字节）
-p
发送post请求时需要上传的文件，此外还必须设置-T参数
-u
发送put请求时需要上传的文件，此外还必须设置-T参数
-T
用于设置Content-Type请求头信息
-v
指定打印帮助信息的冗余级别
-w
以html表格形式打印结果
-i
使用HEAD请求代替GET请求
-x
插入字符串作为table标签的属性
-y
字符串作为tr标签的属性
-z
插入字符串作为td标签的属性
-C
添加cookie信息
-H
添加任意的请求头
-A
添加一个基本的网格认证信息
-P
添加一个基本的代理认证信息
-X
指定使用的端口号
-V
打印版本号并退出
-k
使用HTTP的KeepAlive特性
-d
不显示百分比
-S
不显示预估和警告信息
-g
输出结果信息到gnuplot格式的文件中
-e
输出结果信息到CSV格式的文件中
-r
指定接收错误信息时不退出程序
-h
用法信息

结果说明

This is ApacheBench, Version 2.3 <$Revision: 1706008 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/
//以上为apache的版本信息

Benchmarking www.baidu.com (be patient).....done
//以上内容显示测试完成度，本次测试发起请求数量较少，完成较快，无中间过程显示。
//在请求数量很多时会分行显示当前完成数量。

Server Software:        bfe/1.0.8.14
//被测试的服务器所用的软件信息，这里使用的是百度自己开发的反向代理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:      10 
//并发级别，也就是并发数，请求中－c参数指定的数量

Time taken for tests:   1.093 seconds 
//本次测试总共花费的时间

Complete requests:      100 
//本次测试总共发起的请求数量

Failed requests:        0 
//失败的请求数量。因网络原因或服务器性能原因，发起的请求并不一定全部成功，
//通过该数值和Complete requests相除可以计算请求的失败率，作为测试结果的重要参考。

Total transferred:      103314 bytes  
//总共传输的数据量，指的是ab从被测服务器接收到的总数据量，
//包括index.html的文本内容和请求头信息。

HTML transferred:       22700 bytes 
//从服务器接收到的index.html文件的总大小，等于
//Document Length＊Complete requests＝227 bytes＊100＝22700 bytes

Time per request:       109.287 [ms] (mean) 
//从用户角度看，完成一个请求所需要的时间（因用户数量不止一个，
//服务器完成10个请求，平均每个用户才接收到一个完整的返回，所以该值是下一项数值的10倍。）

Time per request:       10.929 [ms] (mean, across all concurrent requests)
// 服务器完成一个请求的时间。


Transfer rate:          92.32 [Kbytes/sec] received 　
//网络传输速度。对于大文件的请求测试，这个值很容易成为系统瓶颈所在。
//要确定该值是不是瓶颈，需要了解客户端和被测服务器之间的网络情况，
//包括网络带宽和网卡速度等信息。

//这几行组成的表格主要是针对响应时间也就是第一个Time per request进行细分和统计。
//一个请求的响应时间可以分成网络链接（Connect），系统处理（Processing）和等待（Waiting）
//三个部分。表中min表示最小值； mean表示平均值；[+/-sd]表示标准差（Standard Deviation） ，
//也称均方差（mean square error），这个概念在中学的数学课上学过，表示数据的离散程度，
//数值越大表示数据越分散，系统响应时间越不稳定。 median表示中位数； max当然就是表示最大值了。

//需要注意的是表中的Total并不等于前三行数据相加，因为前三行的数据并不是在同一个请求中采集到的，
//可能某个请求的网络延迟最短，但是系统处理时间又是最长的呢。
//所以Total是从整个请求所需要的时间的角度来统计的。这里可以看到最慢的一个请求花费了195ms，
//这个数据可以在下面的表中得到验证。


Percentage of the requests served within a certain time (ms)

  50%    106

  66%    109

  75%    111

  80%    114

  90%    118

  95%    154

  98%    176

  99%    195

 100%    195 (longest request)

//这个表第一行表示有50%的请求都是在106ms内完成的，
//可以看到这个值是比较接近平均系统响应时间
//（第一个Time per request:       109.287 [ms] (mean) ）

//以此类推，90%的请求是小于等于118ms的。刚才我们看到响应时间最长的那个请求是195ms，
//那么显然所有请求（100%）的时间都是小于等于195毫秒的，
//也就是表中最后一行的数据肯定是时间最长的那个请求（longest request）。

HTTP keep-alive

在早期的HTTP/1.0中，每次http请求都要创建一个连接，而创建连接的过程需要消耗资源和时间，为了减少资源消耗，缩短时间，就需要重用连接。在后的的HTTP1.0和HTTP1.1中，引入了重用连接的机制，就是在http请求头中加入Connection:keep-alive来告诉对方这个请求响应完成后不要关闭，下一次利用这个连接。协议规定HTTP1.0如果想要保持长连接，需要在请求头中加上Connection:keep-alve，而HTTP1.1默认是支持的长连接的，有没有这个请求头都行。

1、优缺点

优点：Keep-Alive模式更加高效，因为避免了连接建立和释放的开销。

缺点：长时间的TCP连接容易导致系统资源无效占用，浪费系统资源。

2、当保持长连接时，如何判断一次请求已完成

Content-Length表示实体内容的长度，浏览器通过这个字段判断当前请求的数据是否已全部接收。所以，当浏览器请求的是一个静态资源时，即服务器能明确知道内容的长度时，可以设置Content-Length来控制请求的结束。但当服务器不知道请求结果的长度时，Content-Length就无法解决上面的问题，这个时候就需要用到Transfer-Encoding字段。

Transfer-Encoding是指传输编码，在上面的问题中，当服务端无法知道实体内容的长度时，就可以通过指定Transfer-Encoding:chuncked来告知浏览器当前的编码是将数据分成一块一块传递的。最后，当浏览器接收到一个长度为0的chuncked时，知道当前请求内容已全部接收。

3、Keep-Alive timeout

httpd守护进程，一般都提供了keep-alive timeout时间设置参数。这个keepalive_timeout时间意味着：一个http产生的tcp连接在传递完最后一个响应后，还要hold住keepalive_timeout秒后，才开始关闭这个连接。

4、Tcp的keepalive

支持三个系统内核配置参数：

net.ipv4.tcp_keepalive_intvl = 15 
net.ipv4.tcp_keepalive_probes = 5 
net.ipv4.tcp_keepalive_time = 1800 

keepalive是TCP保鲜定时器，当网络两端建立了TCP连接之后，闲置了tcp_keepalive_time后，服务器就会尝试向客户端发送侦测包，来判断TCP连接状况。如果没有收到对方的回答（ack），则会在tcp_keepalive_intvl后再次尝试发送侦测包，直到收到对方的ack，如果一直没有收到对方的ack，一共会尝试tcp_keepalive_probes次，如依然没有收到对方的ack包，则会丢弃该TCP连接。