性能压力测试工具之ApacheBench

​

1、ApacheBench命令原理：

1. ab命令会创建很多的并发访问线程，模拟多个访问者同时对某一URL地址进行访问。
2. 试目标是基于URL，可以用来测试Apache的负载压力，也可以测试nginx、lighthttp、tomcat、IIS等其它Web服务器的压力。
3. ab命令对发出负载的计算机要求很低，既不会占用很高CPU，也不会占用很多内存，但却会给目标服务器造成巨大的负载，其原理类似CC攻击。自己测试使用也须注意，否则一次上太多的负载，可能造成目标服务器因资源耗完，严重时甚至导致死机。
   执行的程序

2、语法及参数

ab [options] [http[s]://]hostname[:port]/path

参数选项

Options are:
    -n requests    #执行的请求数，即一共发起多少请求。
    -c concurrency    #请求并发数。
    -t timelimit    #测试所进行的最大秒数。其内部隐含值是-n 50000，它可以使对服务器的测试限制在一个固定的总时间以内。默认时，没有时间限制。
    -s timeout    #指定每个请求的超时时间，默认是30秒。
    -b windowsize    #指定tcp窗口的大小，单位是字节。
    -B address    #指定在发起连接时绑定的ip地址是什么。
    -p postfile    #指定要POST的文件，同时要设置-T参数。
    -u putfile    #指定要PUT的文件，同时要设置-T参数。
    -T content-type    #指定使用POST或PUT上传文本时的文本类型，默认是'text/plain'。
    -v verbosity    #设置详细模式等级。
    -w    #将结果输出到html的表中。
    -i    #使用HEAD方式代替GET发起请求。
    -y attributes    #以表格方式输出时，设置html表格tr属性。 
    -z attributes    #以表格方式输出时，设置html表格th或td属性。
    -C attribute    #添加cookie,比如'Apache=1234'。（可重复）
    -H attribute    #为请求追加一个额外的头部，比如'Accept-Encoding: gzip'。（可重复）
    -A attribute    #对服务器提供BASIC认证信任。用户名和密码由一个:隔开，并以base64编码形式发送。无论服务器是否需要(即,是否发送了401认证需求代码)，此字符串都会被发送。
    -P attribute    #对一个中转代理提供BASIC认证信任。用户名和密码由一个:隔开，并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。
    -X proxy:port   #指定代理服务器的IP和端口。
    -V              #打印版本信息。
    -k              #启用HTTP KeepAlive功能，即在一个HTTP会话中执行多个请求。默认时，不启用KeepAlive功能。
    -d              #不显示"percentage served within XX [ms] table"的消息(为以前的版本提供支持)。
    -q              #如果处理的请求数大于150，ab每处理大约10%或者100个请求时，会在stderr输出一个进度计数。此-q标记可以抑制这些信息。
    -g filename     #把所有测试结果写入一个'gnuplot'或者TSV(以Tab分隔的)文件。此文件可以方便地导入到Gnuplot,IDL,Mathematica,Igor甚至Excel中。其中的第一行为标题。
    -e filename     #产生一个以逗号分隔的(CSV)文件，其中包含了处理每个相应百分比的请求所需要(从1%到100%)的相应百分比的(以微妙为单位)时间。由于这种格式已经“二进制化”，所以比'gnuplot'格式更有用。
    -r              #当收到错误时不要退出。
    -h              #输出帮助信息
    -Z ciphersuite  指定SSL/TLS密码套件
    -f protocol     指定SSL/TLS协议(SSL3, TLS1, TLS1.1, TLS1.2 or ALL)
 

3、安装

3.1、Window系统

1. 下载，解压
2. 打开cmd命令行窗口，cd到apache安装目录的bin目录下

3.2、linux系统

yum install httpd-tools

4、案例

ab -n 4000 -c 1000 http://localhost:8080/EX2/responseCode

-n:后面的4000代表总共发出4000个请求；
-c:后面的1000表示采用1000个并发（模拟1000个人同时访问），

后面的网址表示测试的目标URL。

H:\java\Apache24\bin>ab -n 4000 -c 1000 http://localhost:8080/EX2/responseCode
 
 
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
 
Benchmarking localhost (be patient)
Completed 400 requests
Completed 800 requests
Completed 1200 requests
Completed 1600 requests
Completed 2000 requests
Completed 2400 requests
Completed 2800 requests
Completed 3200 requests
Completed 3600 requests
Completed 4000 requests
Finished 4000 requests
 
 
Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost 	//测试地址
Server Port:            8080 		//测试端口
 
Document Path:          /EX2/responseCode //测试的url
Document Length:        2 bytes 	//文档大小（该测试返回的内容只有OK两字）
 
Concurrency Level:      1000  		//测试的并发数
Time taken for tests:   1.806 		//seconds 整个测试持续的时间
Complete requests:      4000 		//完成的请求数量
Failed requests:        0 			//失败的请求数量
Non-2xx responses:      4000
Total transferred:      668000 bytes //整个过程中的网络传输量
HTML transferred:       8000 bytes   //整个过程中的HTML内容传输量
Requests per second:    2214.84 [#/sec] (mean) 	//重要指标:相当于LR中的每秒事务数，后面括号中的mean表示这是一个平均值
Time per request:       451.500 [ms] (mean) 	//重要指标:当于LR中的平均事务响应时间，后面括号中的mean表示这是一个平均值
Time per request:       0.452 [ms] (mean, across all concurrent requests)//每个连接请求实际运行时间的平均值
Transfer rate:          361.21 [Kbytes/sec] received //平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题
 
Connection Times (ms) min  mean[+/-sd] median   max
Connect:       			0    0   8.0      0     504
Processing:    			54  298 127.9    307     825
Waiting:        		3  173 152.9    148     813
Total:         			54  298 128.1    307     825
 
Percentage of the requests served within a certain time (ms)
  50%    307
  66%    313
  75%    314
  80%    315
  90%    315
  95%    317
  98%    821
  99%    824
 100%    825 (longest request)
 //其中50％的用户响应时间小于307毫秒，66％的用户响应时间小于313毫秒，最大的响应时间小于825毫秒。对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数

​