zoukankan      html  css  js  c++  java
  • web压力测试工具(小而精)

    实际的测试过程中,我们一般都是采用A、B两台机器,一台跑Web服务,另外一台跑ab测试。也有的情况是单机对单机可能测不出结果,那就要采用很多台机器同是跑AB去请求一台机器进行测试,根据多台机器反馈的结果才能够得出一个科学的测试结果。

    1.APACHE ab

    ab是Apache超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache的执行性能,主要是显示你安装的Apache每秒可以处理多少个请求。

    ab 不像 LR 那么强大,但是它足够轻便,如果只是在开发过程中想检查一下某个模块的响应情况,或者做一些场景比较简单的测试,ab 还是一个不错的选择。

    1.1.  参数说明

     

    -n requests

    在测试会话中所执行的请求个数。默认仅执行一个请求,此时其结果不具有意义。

    -c concurrency

    一次产生的请求个数。默认是一次一个。

    -t timelimit

    测试所进行的最大秒数。内部隐含值是"-n 50000"。它可以使对服务器的测试限制在一个固定的总时间以内。默认时,没有时间限制。

    -p POST-file

    包含了POST数据的文件。

    -T content-type

    POST数据时所使用的"Content-type"头信息。

    -v verbosity

    设置显示信息的详细程度,4或更大值会显示头信息,3或更大值可以显示响应代码(404,200等),2或更大值可以显示警告和其他信息。

    -w

    以HTML表格形式输出结果。默认时,它是白色背景的两列宽度的一张表。

    -i

    执行HEAD请求,而不是GET 。

    -x <table>-attributes

    设置<table>属性的字符串。此属性被填入<table 这里 > 。

    -y <tr>-attributes

    设置<tr>属性的字符串。

    -z <td>-attributes

    设置<td>属性的字符串。

    -C cookie-name=value

    对请求附加一个"Cookie:"头行。其典型形式是 name=value 的一个参数对。此参数可以重复。

    -H custom-header

    对请求附加额外的头信息。此参数的典型形式是一个有效的头信息行,其中包含了以冒号分隔的字段和值(如:"Accept-Encoding: zip/zop;8bit")。

    -A auth-username:password

    向服务器提供基本认证信息。用户名和密码之间由一个":"隔开,并将被以base64编码形式发送。无论服务器是否需要(即是否发送了401认证需求代码),此字符串都会被发送。

    -P proxy-auth-username:password

    对一个中转代理提供基本认证信息。用户名和密码由一个":"隔开,并将被以base64编码形式发送。无论服务器是否需要(即是否发送了407代理认证需求代码),此字符串都会被发送。

    -X proxy[:port]

    对请求使用代理服务器。

    -V

    显示版本号并退出。

    -k

    启用KeepAlive功能,即在一个HTTP会话中执行多个请求。默认不启用KeepAlive功能。

    -d

    不显示"percentage served within XX [ms] table"消息(为以前的版本提供支持)。

    -S

    不显示中值和标准偏差值,而且在均值和中值为标准偏差值的1到2倍时,也不显示警告或出错信息。默认时,会显示最小值/均值/最大值等数值。(为以前的版本提供支持)

    -g gnuplot-file

    把所有测试结果写入一个"gnuplot"或者TSV(以Tab分隔)文件。此文件可以方便地导入到 Gnuplot, IDL, Mathematica, Excel中。其中的第一行为标题。

    -e csv-file

    产生一个逗号分隔(CSV)文件,其中包含了处理每个相应百分比请求(从1%到100%)所需要的相应百分比时间(以微秒为单位)。由于这种格式已经"二进制化",所以比"gnuplot"格式更有用。

    -h

    显示使用方法的帮助信息。

    1.2.  举例

    ab -c 10 -n 10 -t 30 http://www.google.com/
    
    输出样例:
    
    This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
    
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    
    Copyright 2006 The Apache Software Foundation, http://www.apache.org/
    
     
    
    Benchmarking www.google.com (be patient)
    
    Finished 779 requests
    
     
    
     
    
    Server Software:        gws
    
    Server Hostname:        www.google.com
    
    //服务器主机名
    
    ServerPort:            80
    
    //服务器端口
    
    Document Path:          /
    
    //测试的页面文档
    
    Document Length:        458 bytes
    
    //文档大小
    
    Concurrency Level:      10
    
    //并发数
    
    Time taken for tests:   30.87239 seconds
    
    //整个测试持续的时间
    
    Complete requests:      779
    
    //完成的请求数量
    
    Failed requests:        0
    
    //失败的请求数量
    
    Write errors:           0
    
    Non-2xx responses:      779
    
    Total transferred:      1004131 bytes
    
    //整个场景中的网络传输量
    
    HTML transferred:       356782 bytes
    
    //整个场景中的HTML内容传输量
    
    Requests per second:    25.89 [#/sec] (mean)
    
    //大家最关心的指标之一,相当于 LR 中的 每秒事务数 ,后面括号中的 mean 表示这是一个平均值
    
    Time per request:       386.229 [ms] (mean)
    
    //大家最关心的指标之二,相当于 LR 中的 平均事务响应时间 ,后面括号中的 mean 表示这是一个平均值
    
    Time per request:       38.623 [ms] (mean, across all concurrent requests)
    
    //每个请求实际运行时间的平均值
    
    Transfer rate:          32.57 [Kbytes/sec] received
    
    //平均每秒网络上的流量,可以帮助排除是否存在网络流量过大导致响应时间延长的问题
    
    Connection Times (ms)
    
                  min  mean[+/-sd] median   max
    
    Connect:       36  167 100.1    132     735
    
    Processing:    62  215 143.6    171     910
    
    Waiting:       61  203 117.4    167     909
    
    Total:         98  382 175.8    344    1243
    
    //网络上消耗的时间的分解,各项数据的具体算法还不是很清楚
    
    /*下面的内容为整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间,其中 50% 的用户响应时间小于 3064 毫秒,60 % 的用户响应时间小于 3094 毫秒,最大的响应时间小于 3184 毫秒*/
    
    Percentage of the requests served within a certain time (ms)
    
      50%    344
    
      66%    395
    
      75%    451
    
      80%    520
    
      90%    626
    
      95%    716
    
      98%    931
    
      99%    977
    
     100%   1243 (longest request)

    2.webbench

    webbench是有名的网站压力测试工具,它是由Lionbridge公司(http://www.lionbridge.com)开发。它的帮助文件和文档请到:http://home.tiscali.cz/~cz210552/webbench.html 上查看。

    Webbech 能测试处在相同硬件上,不同服务的性能以及不同硬件上同一个服务的运行状况。webBech的标准测试可以向我们展示服务器的两项内容:每秒钟相应请求数 和每秒钟传输数据量。webbench不但能具有便准静态页面的测试能力,还能对动态页面(ASP,PHP,JAVA,CGI)进行测试的能力。还有就是 他支持对含有SSL的安全网站例如电子商务网站进行静态或动态的性能测试。

    2.1.  参数说明

     

    -f –force

    不等服务器回复

    -r –reload

    发送重新load请求,等同于Pragma:no-cache.

    -t –time

    测试所进行的最大秒数。默认30。

    -p –proxy

    使用代理服务器

    -c --clients

    一次产生的请求个数。默认是1。

    -9 --http09

    使用http/0.9协议

    -1 --http10

    使用http/1.0协议

    -2 –http11

    使用http/1.1协议

    --get

    使用get请求方法

    --head

    使用head请求方法

    --options

    使用options请求方法

    --trace

    使用trace请求方法

    -? –h –help

    显示帮助信息

    -V –version

    显示程序的版本信息

    2.2.  例子

    webbench -c 100 -t 30 http://www.google.com/

    输出样例:

    Webbench - Simple Web Benchmark 1.5
    
    Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
    
     
    
    Benchmarking: GET http://www.google.com/
    
    100 clients, running 30 sec.
    
     
    
    Speed=4028 pages/min, 86577 bytes/sec.
    
    Requests: 2014 susceed, 0 failed.

    3.http_load

    程序非常小,解压后也不到100K

    http_load以并行复用的方式运行,用以测试web服务器 的吞吐量与负载 。但是它不同于大多数压力测试工具,它可以以一个单一的进程运行,一般不会把客户机搞死。还可以测试HTTPS类的网站请求。

    官网:http://www.acme.com/software/http_load/

    下载地址:

    wget http://www.acme.com/software/http_load/http_load-12mar2006.tar.gz

    3.1.  参数说明

     

    -parallel 简写-p :含义是并发的用户进程数。

    -fetches 简写-f :含义是总计的访问次数

    -rate    简写-r :含义是每秒的访问频率

    -seconds简写-s :含义是总计的访问时间

    3.2.  例子

    http_load -p 20 -f 20 www.chedong.com.url

    输出样例:

    20 fetches, 20 max parallel, 790105 bytes, in 4.34421 seconds
    
    //说明在上面的测试中运行了20个请求,最大的并发进程数是20,总计传输的数据是790105bytes,运行的时间是4.34421秒
    
    39505.2 mean bytes/connection
    
    //说明每一连接平均传输的数据量790105/20=39505.2
    
    4.60383 fetches/sec, 181875 bytes/sec
    
    //说明每秒的响应请求为4.60383,每秒传递的数据为181875 bytes/sec
    
    msecs/connect: 305.351 mean, 3151.05 max, 146.267 min
    
    //说明每连接的平均响应时间是305.351msecs,最大的响应时间3151.05msecs,最小的响应时间146.267msecs
    
    msecs/first-response: 772.81 mean, 1555.86 max, 155.245 min
    
    HTTP response codes:
    
      code 200 -- 20
    
    //说明打开响应页面的类型,如果403的类型过多,那可能要注意是否系统 遇到了瓶颈。

     

    4.Siege

    虽然Apache自带一个压力测试工具ab,但是ab的功能太简单了,无法模拟真实的web访问,所以我们要用到更加强大的web压力测试工具——Siege。Siege(英文意思是围攻)是一个压力测试和评测工具,设计用于WEB开发这评估应用在压力下的承受能力:可以根据配置对一个WEB站点进行多用户的并发访问,记录每个用户所有请求过程的相应时间,并在一定数量的并发访问下重复进行。

    Siege时一个开放源代码项目:http://www.joedog.org/siege/下载:

    wget ftp://sid.joedog.org/pub/siege/siege-latest.tar.gz

    4.1.  参数说明

     

    -cNUM

      设置并发的用户(连接)数量,比如-c10,设置并发10个连接。默认的连接数量可以到~/.siegerc中查看,指令为concurrent = x,前面咱们已经调整了默认并发连接为50。

    -rNUM

      (repetitions),重复数量,即每个连接发出的请求数量,设置这个的话,就不需要设置-t了。对应.siegerc配置文件中的reps = x指令

    -tNUM

      (time),持续时间,即测试持续时间,在NUM时间后结束,单位默认为分,比如-t10,那么测试时间为10分钟,-t10s,则测试时间为10秒钟。对应.siegerc中的指令为time = x指令

    -b

      (benchmark),基准测试,如果设置这个参数的话,那么delay时间为0。在.siegerc中咱们修改为默认开启。

    -f url.txt

     (file),这是url列表文件。对应.siegerc配置文件中的file = x指令

    4.2.  例子

    siege -c 20 -r 20 -f www.chedong.com.url

    www.chedong.com.url内容:

    http://www.chedong.com/tech/

    http://www.chedong.com/tech/acdsee.html

    http://www.chedong.com/tech/ant.html

    http://www.chedong.com/tech/apache_install.html

    http://www.chedong.com/tech/awstats.html

    http://www.chedong.com/tech/cache.html

    http://www.chedong.com/tech/click.html

    http://www.chedong.com/tech/cms.html

    http://www.chedong.com/tech/compress.html

    http://www.chedong.com/tech/cvs_card.html

    http://www.chedong.com/tech/default.html

    http://www.chedong.com/tech/dev.html

    http://www.chedong.com/tech/gnu.html

    输出样例:

    Lifting the server siege… done.
    
    Transactions:                    400 hits //完成400次处理
    
    Availability:                 100.00 % //100.00 % 成功率
    
    Elapsed time:                  34.61 secs //总共用时
    
    Data transferred:               3.94 MB //共数据传输3.94MB
    
    Response time:                  1.37 secs //相应用时1.37秒:显示网络连接的速度
    
    Transaction rate:              11.56 trans/sec //平均每秒完成11.56次处理:表示服务器后台处理的速度
    
    Throughput:                     0.11 MB/sec //平均每秒传送数据0.11MB
    
    Concurrency:                   15.87 //实际最高并发数15.87
    
    Successful transactions:         400 //成功处理次数
    
    Failed transactions:               0 //失败处理次数
    
    Longest transaction:           11.13 //每次传输所花最长时间
    
    Shortest transaction:           0.34 //每次传输所花最短时间

     

    5. 对比

    输出压力的能力:

    软件

    每秒处理数

    webbench

    4876

    ab

    4059

    http_load

    3148

    siege

    1822

    从上面可以看过,webbench 能力最强, ab 紧接着来的。其它的压力软件,能打出的每秒的能力差些。

    功能对比

     针对一些常用的功能,进行了一下对比,方便我们选择自己合适的测试软件。

     

    自定义http头

    url列表

    随机 URL

    https支持

    KeepAlive

    cookie支持

    HTTP1.0/1支持

    认证支持

    时间测试压力

    webbench

     

     

     

     

     

     

    yes

     

    yes

    ab

    yes

     

     

     

    yes

    yes

     

    yes

     

    http_load

     

    yes

    yes

    yes

     

     

     

     

    yes

    siege

    yes

    yes

    yes

    yes

     

     

     

     

     

    注意:

    1)   实际的测试过程中,我们一般都是采用A、B两台机器,一台跑Web服务,另外一台跑ab测试。也有的情况是单机对单机可能测不出结果,那就要采用很多台机器同是跑AB去请求一台机器进行测试,根据多台机器反馈的结果才能够得出一个科学的测试结果。做压力测试时,该软件自身也会消耗CPU和内存资源,为了测试准确,请将测试软件安装在别的服务器上。

    2)   不要测试上线之后的网站,压垮了可不好玩。

    3)   ab -n 100 -c 10 http://www.baidu.com/ ——(注意,这里要保留 "/" 根目录哦);webbench也是一样。

  • 相关阅读:
    spring mvc之DispatcherServlet类分析
    python根据操作系统类型调用特定模块
    C#编写windows服务程序
    写在开始前---多端小系统结构
    写在开始前---web异常处理
    java反射
    写在开始前---简单业务分层
    写在开始前---ajax中的会话过期与重新登录
    一个简易的netty udp服务端
    google的python语言规范
  • 原文地址:https://www.cnblogs.com/tuyile006/p/3635261.html
Copyright © 2011-2022 走看看