ab和LoadRunner的区别，及ab的运用方法

来源：互联网发布：中国制裁挪威知乎编辑：程序博客网时间：2024/04/25 22:14

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时间乘以并发请求数

转载地址：http://blog.csdn.net/gzh0222/article/details/7172341