PHP性能:序——谈ab(Apache Bench)压力测试工具

来源:互联网 发布:手机淘宝上买东西教程 编辑:程序博客网 时间:2024/06/01 22:28

ab(Apache  Bench)是啥?

  ab是Apache自带的一个压力测试软件,可以通过ab命令和选项对某个URL进行压力测试。ab建议在linux环境下使用。

 

为啥要压力测试工具?

  因为你不给你的网站压力,你不知道项目的最大的容量是多少,自己的知识有多少。在一定范围里,压力达到一定程度,动力和容量也就达到顶峰。所以说没有最大的容量,只有极致的性能优化。

  压力测试工具,另一方面也为测试提供一个标准,为当前需要优化提供基础数据。

 

ab有什么能力?

  ab作为Apache自带的软件,虽然性能不是最强,但是作为一般的压力测试已经足够了。

  ab的安装

  一般已经安装了Apache就不需要安装,需要安装的话可以自行搜索。

  ab的主要命令

  ab主要使用的两个选项就是-n和-c。其他选项使用命令 ab -h 进行查看。

  命令格式是:    ab -n10 -c10 URL

  命令解说:

  自带的命令选项说明如下

  

  上图所示,-n指的是请求URL的数量,-c是指每次请求的并发数。展示的命令格式的意义就是:对URL进行10次请求,每次并发数是10个,总共请求了100次。

  注:URL最后一定要补充一个"/",如:http://www.baidu.com/

  

测试性能主要关心那几个点?

  对于ab工具,我们需要关注的是服务器软件,每秒请求数(Requests per second),单个请求的耗时(Time per request)。

  下面是测试的结果解析:

  

  

  

测试的几个原则

  1、测试工具和测试数据时,使用到别人的网址时,-n和-c的参数不能太大。

  2、测试当前的机器,最好用另一台机器测试。

  3、测试修改结果,最好是某个功能完善后才测,否则会导致结果有差异。


AB测试,200个请求,20个并发.这样的测试强度,CPU占了70-80%,w3p占用了70多M内存,本想多测几次,看看它的内存会不会涨上去,没 有测试机器没办法,开发机要干活.我估计CPU就有问题了,性能有好些个地方还需要优化.

顺便把测试的工具用法作个记号

基本用法:
ab -n
 全部请求数 -c 并发数 测试url
:ab -n 1000 -c 50 http://www.newdev.gztest.com/
Server Software:        
 Microsoft-IIS/7.0
Server Hostname:       
 www.newdev.gztest.com
Server Port:            80
Document Path:         
Document Length:        82522 bytes  #
请求文档大小

Concurrency Level:      50           #
并发数  
Time taken for tests:   92.76140 seconds #
全部请 求完成耗时
Complete requests:      10000          #
全部请求数
Failed requests:        1974           #
失败的请求
  (Connect: 0, Length: 1974, Exceptions: 0)
Write errors:           0
Total transferred:      827019400 bytes   #
总传输大小 
HTML transferred:       825219400 bytes
 //整个场 景中的HTML内容传输量
Requests per second:    108.61 [#/sec] (mean)   #
每秒请 求数(平均)//大家最关心的指标之一,相当于 LR 中的每秒事务数,后面括 号中的 mean 表示这是一个平均值
Time per request:       460.381 [ms] (mean)   #
每次并发请求时间(所有并发) //大家最关心的指标之二,相当于 LR 中的平均事务响应时间, 后面括号中的 mean 表示这是一个平均值
Time per request:       9.208 [ms] (mean, across all concurrent requests)   #
每一请求时间(并发平均 //每个请求实际运行时间的平均值
Transfer rate:          8771.39 [Kbytes/sec] received    #传输速 率//平 均每秒网络上的流量,可以帮助排除是否存在网络流量过大导致响应时间延长的问题
Percentage of the requests served within a certain time (ms)
 
50%   2680
  66%   2806
  75%   2889
  80%   2996
  90%  11064
  95%  20161
  98%  21092
  99%  21417
 100%  21483 (longest request)
//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间,其 中50%的用户响应时间小于2680毫秒,60% 的用户响应时间小于2806毫秒,最大的响应时间小于21417毫秒
由于对于并发请求,cpu实际上并不是同时处理的,而是按照每个 请求获得的时间片逐个轮转处理的,所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数。

Connection Times (ms)    #连接时 间
             min  mean[+/-sd] median   max
Connect(#
连接):        0    0   2.1      0      46
Processing(#
处理):    31  458  94.7    438    1078
Waiting(#
等待):       15  437  87.5    422     938
Total:         31  458  94.7    438    1078


其 它参数:

-n requests    
 全部请求数
-c concurrency  
并发数
-t timelimit    
最传等待回应时间
-p postfile     POST
数 据文件
-T content-type POST Content-type
-v verbosity    How much troubleshooting info to print
-w              Print out results in HTML tables
-i              Use HEAD instead of 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    
加入cookie, eg. 'Apache=1234. (repeatable)
-H attribute    
加入http, eg. 'Accept-Encoding: gzip'
                Inserted after all normal header lines. (repeatable)
-A attribute    http
验证,分隔传递用户名及密码
-P attribute    Add Basic Proxy Authentication, the attributes
                are a colon separated username and password.
-X proxy:port  
 代理服务器
-V              
查看ab版本
-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)

[原文:http://blog.sina.com.cn/s/blog_46d93f190100hev8.html] 

Apache ab性能测试结果分析

  一直以来我都是用Loadrunner去做性能测试。Loadrunner实际上是一个很重的性能测试工具。他的功能很全面,是一把很好的牛刀。

  如果我们只是需要对一个页面做简单的性能测试,使用Loadruner这把牛刀就不是一个很好的选择了。

  所以就找了把小刀--ab来试试。这把小刀真的是轻巧又锋利,在这里就记录一下对ab测试过程中的一些自己的理解,供大家参考。

  我们就拿百度首页来祭刀吧。首先你得有一把刀,也就是安装好Apache,网上教程一大堆就不复述了,本文使用MacBook自带的ab命令进行测试。

  测试场景:模拟10个用户,对百度首页发起总共100次请求。

  测试命令 ab -n 100 -c 10  https://www.baidu.com/index.html

  本文主要针对ab的测试报告进行解析,有关ab的使用方法改天再新开贴交流。

  测试报告

  

下面来逐行解释我的理解,以下注释部分有查阅网上资料,但所写内容均为自己理解之后手打内容,希望加入自己的理解之后能让读者更容易理解。

bogon:~ tang$ ab -n 100 -c 10  https://www.baidu.com/index.html

This is ApacheBench, Version 2.3 <$Revision: 1706008 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

//以上为apache的版本信息,与本次测试无关

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

//以上内容显示测试完成度,本次测试发起请求数量较少,完成较快,无中间过程显示。在请求数量很多时会分行显示当前完成数量。

 

 

Server Software:        bfe/1.0.8.14    //被测试的服务器所用的软件信息,这里使用的是百度自己开发的反向代理Baidu Front End,类似nginx。

Server Hostname:        www.baidu.com //被测主机名

Server Port:            443 //被测主机的服务端口号,一般http请求的默认端口号是80,https默认使用443端口

SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128  //加密协议

 

Document Path:          /index.html  //请求的具体文件

Document Length:        227 bytes   //请求的文件index.html大小

 

Concurrency Level:      10 //并发级别,也就是并发数,请求中-c参数指定的数量

Time taken for tests:   1.093 seconds //本次测试总共花费的时间

Complete requests:      100 //本次测试总共发起的请求数量

Failed requests:        0 //失败的请求数量。因网络原因或服务器性能原因,发起的请求并不一定全部成功,通过该数值和Complete requests相除可以计算请求的失败率,作为测试结果的重要参考。

Total transferred:      103314 bytes  //总共传输的数据量,指的是ab从被测服务器接收到的总数据量,包括index.html的文本内容和请求头信息。

HTML transferred:       22700 bytes //从服务器接收到的index.html文件的总大小,等于Document Length*Complete requests=227 bytes*100=22700 bytes

Requests per second:    91.50 [#/sec] (mean) //平均(mean)每秒完成的请求数:QPS,这是一个平均值,等于Complete requests/Time taken for tests=100/1.093=91.50

Time per request:       109.287 [ms] (mean) //从用户角度看,完成一个请求所需要的时间(因用户数量不止一个,服务器完成10个请求,平均每个用户才接收到一个完整的返回,所以该值是下一项数值的10倍。)

Time per request:       10.929 [ms] (mean, across all concurrent requests)// 服务器完成一个请求的时间。

Transfer rate:          92.32 [Kbytes/sec] received  //网络传输速度。对于大文件的请求测试,这个值很容易成为系统瓶颈所在。要确定该值是不是瓶颈,需要了解客户端和被测服务器之间的网络情况,包括网络带宽和网卡速度等信息。

 

Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:       47   74  12.9     74     106

Processing:     9   32  20.2     32     106

Waiting:        9   29  19.1     27      98

Total:         66  106  20.8    106     195

//这几行组成的表格主要是针对响应时间也就是第一个Time per request进行细分和统计。一个请求的响应时间可以分成网络链接(Connect),系统处理(Processing)和等待(Waiting)三个部分。表中min表示最小值; mean表示平均值;[+/-sd]表示标准差(Standard Deviation) ,也称均方差(mean square error),这个概念在中学的数学课上学过,表示数据的离散程度,数值越大表示数据越分散,系统响应时间越不稳定。 median表示中位数; max当然就是表示最大值了。

//需要注意的是表中的Total并不等于前三行数据相加,因为前三行的数据并不是在同一个请求中采集到的,可能某个请求的网络延迟最短,但是系统处理时间又是最长的呢。所以Total是从整个请求所需要的时间的角度来统计的。这里可以看到最慢的一个请求花费了195ms,这个数据可以在下面的表中得到验证。

 

Percentage of the requests served within a certain time (ms)

  50%    106

  66%    109

  75%    111

  80%    114

  90%    118

  95%    154

  98%    176

  99%    195

 100%    195 (longest request)

//这个表第一行表示有50%的请求都是在106ms内完成的,可以看到这个值是比较接近平均系统响应时间(第一个Time per request:       109.287 [ms] (mean) )

以此类推,90%的请求是小于等于118ms的。刚才我们看到响应时间最长的那个请求是195ms,那么显然所有请求(100%)的时间都是小于等于195毫秒的,也就是表中最后一行的数据肯定是时间最长的那个请求(longest request)。


阅读全文
0 0
原创粉丝点击