霜天部落 | 关注LAMP高性能、高并发架构的设计与研究

压测工具http_load与apache ab

http_load 简介

http_load以并行复用的方式运行,用以测试Web服务器的吞吐量与负载。但是它不同于大多数压力测试工具,其可以以一个单一的进程运行,这样就不会把客户机搞死,还可以测试HTTPS类的网站请求。关于http_load的详细信息参见这里,点击这里下载。

安装

# tar xzvf http_load-09Mar2016.tar.gz
# cd http_load-09Mar2016
# make && make install

测试

http_load的命令参数比较简单,直接在命令行下执行http_load就能看到,具体如下:

-parallel简写-p:并发的用户进程数。
-fetches简写-f:总计的访问次数
-rate简写-r:每秒的访问频率
-seconds简写-s:总计的访问时间

http_load的命令格式也比较简单,各参数可以自由组合,常用格式如下:

$ http_load -p 并发访问进程数 -f 访问总数 需要访问的URL文件
$ http_load -r 每秒访问频率 -s 访问时间 需要访问的URL文件

通常:参数pf一起使用,参数rs一起使用。

这里以某网页测试为例说明之:

$ vi test.url
http://www.xxxxx.com

当然上面存放请求URL的文件中,可以存放多个URL,每行一个。

$ http_load -p 5 -s 300 test.url
11694 fetches, 5 max parallel, 5.6872e+08 bytes, in 300 seconds
48633.5 mean bytes/connection
38.98 fetches/sec, 1.89573e+06 bytes/sec
msecs/connect: 10.476 mean, 9008.81 max, 5.002 min
msecs/first-response: 36.5928 mean, 5383.94 max, 16.614 min
7 timeouts
10428 bad byte counts
HTTP response codes:
code 200 -- 7552

上面命令表示:5个并发进程,持续300秒请求某网页。

#http_load -r 5 -s 300 test.url
1499 fetches, 5 max parallel, 9.49031e+07 bytes, in 300.017 seconds
63310.9 mean bytes/connection
4.99638 fetches/sec, 316326 bytes/sec
msecs/connect: 21.5961 mean, 3020.17 max, 16.782 min
msecs/first-response: 36.6554 mean, 61.907 max, 17.919 min
1261 bad byte counts
HTTP response codes:
code 200 -- 1261

上面命令表示:每秒频率为5条请求,持续300秒请求某网页。
结果分析如下:
(1)1499 fetches, 5 max parallel, 9.49031e+07 bytes, in 300.017 seconds
说明在上面的测试中运行了1499个请求,最大的并发进程数是5,总计传输的数据是9.49031e+07 bytes,运行的时间是300.017秒
(2)63310.9 mean bytes/connection
说明每个连接平均传输的数据量63310.9/1499=42.24
(3)4.99638 fetches/sec, 316326 bytes/sec
说明每秒的响应请求为4.99638,每秒传递的数据为316326 bytes/sec
(4)msecs/connect: 21.5961 mean, 3020.17 max, 16.782 min
说明每个连接的平均响应时间是21.5961 msecs,最大的响应时间3020.17 msecs,最小的响应时间16.782 msecs
(5)HTTP response codes: code 200 — 1261
说明打开响应页面的类型,如果403的类型过多,那可能要注意是否系统遇到了瓶颈
特殊说明:测试结果中主要的指标是fetches/sec和msecs/connect,即服务器每秒能够响应的请求次数和每个连接的平均响应时间。当然仅有这两个指标并不能完成对性能的分析,这两个指标主要反映的是QPS和RT。此外,还需要对服务器的CPU(idle和load)、Mem进行分析,才能得出结论。
需要注意的是:http_load请求方式默认为GET方式,不支持POST方式。

apache ab 简介

ab即ApacheBench,是apache自带的一款功能强大的测试工具,安装了apache一般就自带了,即httpd(在bin目录下)。ab可以同时模拟多个并发请求,专门用于HTTP Server的benchmark testing。

ab命令格式如下:
ab [options] [http[s]://]hostname[:port]/path
ab的参数比较多,直接在命令行下执行ab就能看到,常用参数如下:
-n在测试会话中所执行的请求个数。默认时,仅执行一个请求。
-c一次产生的请求个数。默认是一次一个。
-t测试所进行的最大秒数。其内部隐含值是-n 50000,它可以使对服务器的测试限制在一个固定的总时间以内。默认时,没有时间限制。
-p包含了需要POST的数据的文件。
-P对一个中转代理提供BASIC认证信任。用户名和密码由一个:隔开,并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码),此字符串都会被发送。
-T POST数据所使用的Content-type头信息。
-v设置显示信息的详细程度-4或更大值会显示头信息,3或更大值可以显示响应代码(404,200等),2或更大值可以显示警告和其他信息。
-V显示版本号并退出。
-w以HTML表的格式输出结果。默认时,它是白色背景的两列宽度的一张表。
-i执行HEAD请求,而不是GET。
-x设置<table>属性的字符串。
-X对请求使用代理服务器。
-y设置<tr>属性的字符串。
-z设置<td>属性的字符串。
-C对请求附加一个Cookie:行。其典型形式是name=value的一个参数对,此参数可以重复。
-H对请求附加额外的头信息。此参数的典型形式是一个有效的头信息行,其中包含了以冒号分隔的字段和值的对(如,”Accept-Encoding:zip/zop;8bit”)。
-A对服务器提供BASIC认证信任。用户名和密码由一个:隔开,并以base64编码形式发送。无论服务器是否需要(即,是否发送了401认证需求代码),此字符串都会被发送。
-h显示使用方法。
-d不显示”percentage served within XX [ms] table”的消息(为以前的版本提供支持)。
-e产生一个以逗号分隔的(CSV)文件,其中包含了处理每个相应百分比的请求所需要(从1%到100%)的相应百分比的(以微妙为单位)时间。由于这种格式已经“二进制化”,所以比’gnuplot’格式更有用。
-g把所有测试结果写入一个’gnuplot’或者TSV(以Tab分隔的)文件。此文件可以方便地导入到Gnuplot,IDL,Mathematica,Igor甚至Excel中。其中的第一行为标题。
-i执行HEAD请求,而不是GET。
-k启用HTTP KeepAlive功能,即在一个HTTP会话中执行多个请求。默认时,不启用KeepAlive功能。
-q如果处理的请求数大于150,ab每处理大约10%或者100个请求时,会在stderr输出一个进度计数。此-q标记可以抑制这些信息。
需要注意的是:ab每次只能测试一个URL,适合做重复压力测试,支持POST方式。

测试

(1)如果要测试POST请求,可以使用如下命令:
$ ab -n 1000000 -c 100 -p data.txt -T 'application/x-protobuf'  'http://www.xxxxx.com/'

上面命令表示模拟100个并发用户,发送1000000个POST请求到http://www.xxxxx.com/,POST数据从文件data.txt读取,Content-type为application/x-protobuf。

$ ab -t 300 -c 100 -p data.txt -T 'application/x-protobuf' 'http://www.xxxxx.com/'

上面命令表示模拟100个并发用户,持续300秒发送POST请求到http://www.xxxxx.com/,POST数据从文件data.txt读取,Content-type为application/x-protobuf。

需要注意的是:如果在发送请求完后,出现如下错误:
apr_poll: The timeout specified has expired (70007)

使用-k参数指定发送keep-alive指令到服务器端,可以解决上面问题:

#ab -t 300 -c 100 -k -p data.txt -T 'application/x-protobuf' 'http://www.xxxxx.com/'

(2)如果要测试GET请求,可以使用如下命令(这里以搜狗首页测试为例说明之):

$ ab -t 300 -c 5 -k http://www.sogou.com

执行上面命令会出现如下错误:

ab: invalid URL
Usage: ab [options] [http[s]://]hostname[:port]/path

上面错误的意思是URL后面要加/path,从提示也能看出来,可以改成如下即可:

$ ab -t 300 -c 5 -k http://www.sogou.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.sogou.com (be patient)
Completed 5000 requests
Finished 5211 requests

Server Software:        nginx                   #被测试服务名称
Server Hostname:        www.sogou.com           #请求地址
Server Port:            80                      #请求端口号

Document Path:          /                       #请求页面
Document Length:        15785 bytes             #页面长度

Concurrency Level:      5                       #并发数
Time taken for tests:   300.011 seconds         #整个测试持续的时间
Complete requests:      5211                    #完成的请求数
Failed requests:        0                       #失败的请求数
Write errors:           0
Keep-Alive requests:    0
Total transferred:      86136965 bytes          #总共传输字节数,包含http的头信息等
HTML transferred:       82258493 bytes          #html字节数,实际的页面传递字节数
Requests per second:    17.37 [#/sec] (mean)    #每秒请求数(这是一个非常重要的指标,即服务器的吞吐量)
Time per request:       287.863 [ms] (mean)     #用户平均请求等待时间(这也是一个非常重要的指标,即请求延迟)
Time per request:       57.573 [ms] (mean, across all concurrent requests)    #服务器平均处理时间,即服务器吞吐量的倒数
Transfer rate:          280.38 [Kbytes/sec] received    #每秒网络上的流量(可以帮助排除是否存在网络流量过大导致响应时间延长的问题)

Connection Times (ms)
min     mean[+/-sd]  median     max
Connect:           28       42 215.8     34      9034
Processing:        86      233 2009.8   108     93465
Waiting:           29       71 547.5     37     21034
Total:            114      275 2031.9   143     93493

Percentage of the requests served within a certain time (ms)
50%    143        #50%的请求在143ms内返回
66%    148        #60%的请求在148ms内返回
75%    154
80%    160
90%    179
95%    195
98%    469
99%   3158
100%  93493 (longest request)    #最大响应时间小于93493ms

特殊说明:测试结果中主要的指标是Requests per second和Time per request(第一个),即每秒请求数和用户平均请求等待时间,这两个指标主要反映的是QPS和RT。