手机GPU检测工具

转载

岁月如歌甚好 2024-11-25 15:01:30

文章标签 手机GPU检测工具运维 php 服务器 Time 文章分类 游戏开发

常用性能测试工具

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:///uncategorized/choose-vps.html
http:///vps-cp/hypervm-tutorial.html
http:///coupons/diavps-april-coupons.html
http:///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）。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。