ab测试与loadrunner

ab的全称是ApacheBench，是Apache附带的一个小工具，专门用于HTTP Server的benchmark testing，可以同时模拟多个并发请求。这个小工具在apache的bin目录下面，但是每次使用都要先跳到该目录下，为了能够直接在cmd下使用，可以讲ab.exe这个文件移到C:\WINDOWS\system32路径下，这样每次使用就很方便了。

loadrunner用的好好的为什么要研究这个ab呢？我给我自己的理由是：

1.ab是开源的，很多大公司都喜欢开源的因为loadrunner太贵了，所以想成为一个性能测试高手必须要懂几个开源的性能测试工具，个人意见；

2.ab这个工具小巧使用并且很简单，上手快学习起来比较简单，而loadrunner相比起来就太复杂了，脚本开发抛开不说，就loadrunner这个工具就够学上个一个月的。

3.ab虽然很小，但是功能还是 很强大的，提供的数据足够我们使用了，其实loadrunner中虽然提供了很多功能，但是我们用能使用多少呢，性能监控这块，我 基本不用全部都是第三方监控或者linux命令，loadrunner中给出的很多指标对我们很有用的也就是1、事物的响应时间 2、事物的成功率 3、系统的吞吐量 3、在单位时间内完成的事物数这些ab基本上都可以实现。

4.如果遇到临时任务或者很简单的一个测试，可以这么说吧，开发写了一个接口让你帮他看一下性能如何，只需大概，正好你有没有loadrunner安装包，那怎么办呢，其他不说就下个loadrunner安装包估计就让开发等的不耐烦了，使用ab就不一样了很快就可以给他结果；

总而言之2者各有特点，如果做大项目，逻辑关系比较复杂的项目ab就无能为力了，所以做为一名性能测试人员就必须掌握2~3种性能测试工具，不同情况下可以使用不同的测试工具。

说了这么对废话，咱们下面就看一看这块小巧的性能测试工具吧：

我们在使用一个新工具之前当然首先看的帮助文档了，那下面我们就看看ab这个工具的帮助文档：

-n requests Number of requests to perform
//在测试会话中所执行的请求个数。默认时，仅执行一个请求
-c concurrency Number of multiple requests to make
//一次产生的请求个数。默认是一次一个。
-t timelimit Seconds to max. wait for responses
//测试所进行的最大秒数。其内部隐含值是-n 50000。它可以使对服务器的测试限制在一个固定的总时间以内。默认时，没有时间限制。
-p postfile File containing data to POST
//包含了需要POST的数据的文件.
-T content-type Content-type header for POSTing
//POST数据所使用的Content-type头信息。
-v verbosity How much troubleshooting info to print
//设置显示信息的详细程度 - 4或更大值会显示头信息， 3或更大值可以显示响应代码(404, 200等), 2或更大值可以显示警告和其他信息。 -V 显示版本号并退出。
-w Print out results in HTML tables
//以HTML表的格式输出结果。默认时，它是白色背景的两列宽度的一张表。
-i Use HEAD instead of GET
// 执行HEAD请求，而不是GET。
-x attributes String to insert as table attributes
//
-y attributes String to insert as tr attributes
//
-z attributes String to insert as td or th attributes
//
-C attribute Add cookie, eg. 'Apache=1234. (repeatable)
//-C cookie-name=value 对请求附加一个Cookie:行。 其典型形式是name=value的一个参数对。此参数可以重复。
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
//-P proxy-auth-username:password 对一个中转代理提供BASIC认证信任。用户名和密码由一个:隔开，并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-h Display usage information (this message)

下面是一个很简单的例子：

ab -n 100 -c 10 http://www.baidu.com/

向百度发送100个请求，以10个并发用户同时进行，这就模拟了loadrunner中的并发用户了

his is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.baidu.com (be patient).....done

Server Software: BWS/1.0

//被测试平台使用的web服务器

Server Hostname: www.baidu.com

//服务器主机名
Server Port: 80
//服务器端口号

Document Path: /

//测试的页面的路径，这是在根目录下
Document Length: 7677 bytes

//测试的页面的大小


Concurrency Level: 10 //并发数
Time taken for tests: 9.187500 seconds//整个测试持续的时间
Complete requests: 100//总共完成的请求数
Failed requests: 0//失败的请求数量
Write errors: 0
Total transferred: 805879 bytes//整个场景中的网络传输量
HTML transferred: 767700 bytes//整个场景中的HTML内容传输量
Requests per second: 10.88 [#/sec] (mean)//大家最关心的指标之一，相当于LR中的每秒事务数，后面括号中的mean表示这是一个平均值
Time per request: 918.750 [ms] (mean)//大家最关心的指标之二，相当于LR中的平均事务响应时间，后面括号中的mean表示这是一个平均值
Time per request: 91.875 [ms] (mean, across all concurrent requests)//每个请求实际运行时间的平均值
Transfer rate: 85.55 [Kbytes/sec] received//平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题


Connection Times (ms)
min mean[+/-sd] median max
Connect: 15 90 76.4 62 343
Processing: 47 792 277.9 844 1265
Waiting: 15 434 285.2 406 1203
Total: 93 883 296.5 937 1390
//网络上消耗的时间的分解，相当于loadrunner中的网页细分图

Percentage of the requests served within a certain time (ms)
50% 937
66% 1000
75% 1078
80% 1140
90% 1218
95% 1250
98% 1312
99% 1390
100% 1390 (longest request)

//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于937 毫秒，60％ 的用户响应时间小于1000 毫秒，最大的响应时间小于1390 毫秒

由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数