常用性能测试工具

常用性能测试工具

nginx下的time查看PHP处理时间

time ./test.php
# 这里主要看user这一块
0.00 real         0.00 user         0.00 sys

还有一种方式是通过Nginx的配置文件中日志格式的
系统变量来在记录中记录PHP请求过程和处理时间.
记录在Nginx日志中

基本流程在PHP笔记下的APPAPI性能优化中有详细的记录

http_load压力测试

仅支持GET请求,不支持POST请求
  • 常用参数
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方式。

  • 案例2
准备URL文件:urllist.txt,文件格式是每行一个URL,URL最好超过50-100个测试效果比较好.文件格式

如下:
http://www.vpser.net/uncategorized/choose-vps.html
http://www.vpser.net/vps-cp/hypervm-tutorial.html
http://www.vpser.net/coupons/diavps-april-coupons.html
http://www.vpser.net/security/vps-backup-web-mysql.html
例如:

http_load -p 30 -s 60 urllist.txt
参数了解了,我们来看运行一条命令来看看它的返回结果
命令:% ./http_load -rate 5 -seconds 10 urls说明执行了一个持续时间10秒的测试,每秒的频率为5。

49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds5916 mean bytes/connection4.89274

fetches/sec, 28945.5 bytes/secmsecs/connect: 28.8932 mean, 44.243 max, 24.488 minmsecs/first

-response: 63.5362 mean, 81.624 max, 57.803 minHTTP response codes: code 200 — 49

结果分析:
1.49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
说明在上面的测试中运行了49个请求,最大的并发进程数是2,总计传输的数据是289884bytes,运行的时间是10.0148秒
2.5916 mean bytes/connection说明每一连接平均传输的数据量289884/49=5916
3.4.89274 fetches/sec, 28945.5 bytes/sec
说明每秒的响应请求为4.89274,每秒传递的数据为28945.5 bytes/sec
4.msecs/connect: 28.8932 mean, 44.243 max, 24.488 min说明每连接的平均响应时间是28.8932 msecs

,最大的响应时间44.243 msecs,最小的响应时间24.488 msecs
5.msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
6、HTTP response codes: code 200 — 49     说明打开响应页面的类型,如果403的类型过多,那可能

要注意是否系统遇到了瓶颈。
特殊说明:
测试结果中主要的指标是 fetches/sec、msecs/connect 这个选项,即服务器每秒能够响应的查询次数,

用这个指标来衡量性能。似乎比 apache的ab准确率要高一些,也更有说服力一些。
Qpt-每秒响应用户数和response time,每连接响应用户时间。
测试的结果主要也是看这两个值。当然仅有这两个指标并不能完成对性能的分析,我们还需要对服务器的

cpu、men进行分析,才能得出结论

AB压力测试

# -n 请求数 -c并发数 域名后面的/必须保留
./ab -n1000 -c100 http://www.baidu.com/

请求实例

  • 发送请求

$ ab -n 1000000 -c 100 -p data.txt -T 'application/x-protobuf'  'http://www.baidu.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/'




如果要测试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/

# 请求案例

$ 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


  • 我的简单实例

➜  Desktop ab -n 100 -c 10 http://www.baidu.com/
This is ApacheBench, Version 2.3 <$Revision: 1757674 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

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

# 服务器软件, baidu web server 一般其他的都是nginx或者apache
Server Software:        BWS/1.1
# 目标站点域名
Server Hostname:        www.baidu.com
# 目标站点的端口号
Server Port:            80

Document Path:          /
# 目标站点的文档大小
Document Length:        112486 bytes

Concurrency Level:      10
Time taken for tests:   6.481 seconds
Complete requests:      100
Failed requests:        98
   (Connect: 0, Receive: 0, Length: 98, Exceptions: 0)
Total transferred:      11347715 bytes
HTML transferred:       11252554 bytes

# 每秒接收的请求书
Requests per second:    15.43 [#/sec] (mean)

Time per request:       648.132 [ms] (mean)

# 每个请求的耗时情况
Time per request:       64.813 [ms] (mean, across all concurrent requests)
Transfer rate:          1709.80 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        6   10   5.9      9      48
Processing:    30  618 1199.2    283    6472
Waiting:        9   34  92.4     13     625
Total:         37  628 1198.7    293    6481

Percentage of the requests served within a certain time (ms)
  50%    293
  66%    326
  75%    715
  80%    762
  90%   1651
  95%   3492
  98%   6447
  99%   6481
 100%   6481 (longest request)
  • 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)。

转载于:https://my.oschina.net/chinaliuhan/blog/3065340

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值