文章目录
性能指标
QPS
QPS Queries Per Second 是每秒查询率 ,是一台服务器每秒能够响应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,即每秒的响应请求数。也即是最大吞吐能力。
TPS
TPS Transactions Per Second 也就是事务数/秒。一个事务是指一个客户机向服务器器发送请求然后服务器做出反应的过程。客户端在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。
QPS和TPS区别
个人理解如下:
- Tps即每秒处理事务数,包括了
- 用户请求服务器
- 服务器自己内部的处理
- 服务器返回给用户
这三个过程,每秒能够完成N
个这三个过程,Tps
也就是N
;
- Qps基本类似于Tps,但是不同的是,对于一个页面的一次访问,形成一个
Tps
;但一次页面请求,可能产生多次对服务器的请求,服务器对这些请求,就可计入“Qps
”之中。
例如:访问一个页面会请求服务器3次,一次放,产生一个“T”,产生3个“Q”
例如:一个大胃王一秒能吃10个包子,一个女孩子0.1秒能吃1个包子,那么他们是不是一样的呢?答案是否定的,因为这个女孩子不可能在一秒钟吃下10个包子,她可能要吃很久。这个时候这个大胃王就相当于TPS,而这个女孩子则是QPS。虽然很相似,但其实是不同的
RT,响应时间
响应时间:执行一个请求从开始到最后收到响应数据所花费的总体时间,即从客户端发起请求到收到服务器响应结果的时间。
响应时间RT(Response-time),是一个系统最重要的指标之一,它的数值大小直接反应了系统的快慢。
并发数
并发数(并发度):指系统同时能处理的请求量,同样反映了系统的负载能力,这个数值可以分析机器1s内的访问日志数量来得到
吞吐量
吞吐量是指系统在单位时间内处理请求的数量,TPS、QPS都是吞吐量的常用量化指标。
系统吞吐量要素
- 一个系统的吞吐量(承压能力)与request(请求)对cpu的消耗,外部接口,IO等等紧密关联。
- 单个request 对cpu消耗越高,外部系统接口,IO影响速度越慢,系统吞吐能力越低,反之越高。
重要参数
QPS(TPS),并发数,响应时间
- QPS(TPS):每秒钟request/事务 数量
- 并发数:系统同时处理的request/事务数
- 响应时间:响应时间是指从客户端发一个请求开始计时,到客户端接收到从服务器端返回的响应结果结束所经历的时间,响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。一般取平均响应时间
关系:
- QPS(TPS)=并发数/平均响应时间
- QPS/TPS(衡量系统处理能力的重要指标)
- QPS一般是指每秒钟处理完请求的次数
- TPS一般是指每秒钟处理完的事务次数(一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理,一个事务在分布式处理中,可能会对应多个请求,对于衡量单个接口服务的处理能力,用QPS比较多)。
一个系统吞吐量通常有QPS(TPS),并发数两个因素决定,每套系统这个两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换,内存等等其他消耗导致系统性能下降。
PV
PV(Page View):页面访问量,即页面浏览量或点击量,用户每次刷新即被计算一次。可以统计服务一天的访问日志得到。
UV
UV(Unique Visitor):独立访客,统计1天内访问某站点的用户数。可以统计服务一天的访问日志并根据用户的唯一标识去重得到。响应时间(RT):响应时间是指系统对请求作出响应的时间,一般取平均响应时间。可以通过Nginx、Apache之类的Web Server得到。
DAU
DAU(Daily Active User),日活跃用户数量。常用于反映网站、互联网应用或网络游戏的运营情况。DAU通常统计一日(统计日)之内,登录或使用了某个产品的用户数(去除重复登录的用户),与UV概念相似
MAU
MAU(Month Active User):月活跃用户数量,指网站、app等去重后的月活跃用户数量
系统吞吐量评估
我们在做系统设计的时候就需要考虑CPU运算,IO,外部系统响应因素造成的影响以及对系统性能的初步预估。
而通常情况下,我们面对需求,我们评估出来的出来QPS,并发数之外,还有另外一个维度:日pv。
通过观察系统的访问日志发现,在用户量很大的情况下,各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和QPS我们就可以推算日流量。
通常的技术方法:
- 找出系统的最高TPS和日PV,这两个要素有相对比较稳定的关系(除了放假、季节性因素影响之外)
- 通过压力测试或者经验预估,得出最高TPS,然后跟进1的关系,计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不一样,这两个客户群的网络行为不应用,他们之间的TPS和PV关系比例也不一样。
软件性能测试的基本概念和计算公式
软件做性能测试时需要关注哪些性能呢?
首先,开发软件的目的是为了让用户使用,我们先站在用户的角度分析一下,用户需要关注哪些性能。
对于用户来说,当点击一个按钮、链接或发出一条指令开始,到系统把结果已用户感知的形式展现出来为止,这个过程所消耗的时间是用户对这个软件性能的直观印 象。也就是我们所说的响应时间,当相应时间较小时,用户体验是很好的,当然用户体验的响应时间包括个人主观因素和客观响应时间,在设计软件时,我们就需要 考虑到如何更好地结合这两部分达到用户最佳的体验。如:用户在大数据量查询时,我们可以将先提取出来的数据展示给用户,在用户看的过程中继续进行数据检 索,这时用户并不知道我们后台在做什么。
用户关注的是用户操作的相应时间。
其次,我们站在管理员的角度考虑需要关注的性能点。
- 响应时间
- 服务器资源使用情况是否合理
- 应用服务器和数据库资源使用是否合理
- 系统能否实现扩展
- 系统最多支持多少用户访问、系统最大业务处理量是多少
- 系统性能可能存在的瓶颈在哪里
- 更换那些设备可以提高性能
- 系统能否支持7×24小时的业务访问
再次,站在开发(设计)人员角度去考虑。
- 架构设计是否合理
- 数据库设计是否合理
- 代码是否存在性能方面的问题
- 系统中是否有不合理的内存使用方式
- 系统中是否存在不合理的线程同步方式
- 系统中是否存在不合理的资源竞争
实际举例
我们通过一个实例来把上面几个概念串起来理解。按二八定律来看,如果每天 80% 的访问集中在 20% 的时间里,这 20% 时间就叫做峰值时间。
公式:( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
机器:峰值时间每秒QPS / 单台机器的QPS = 需要的机器
- 每天300w PV 的在单台机器上,这台机器需要多少QPS?
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
- 如果一台机器的QPS是58,需要几台机器来支持?
139 / 58 = 3
linux系统使用ab进行压力测试
ab的简介
ab是apachebench命令的缩写。
ab是apache自带的压力测试工具。ab非常实用,它不仅可以对apache服务器进行网站访问压力测试,也可以对或其它类型的服务器进行压力测试。比如nginx、tomcat、IIS等
ab的原理
ab的原理:ab命令会创建多个并发访问线程,模拟多个访问者同时对某一个URL地址进行访问,它的测试目标是基于URL的,因此,它既可以用来测试apache的负载压力,也可以测试nginx、lighthttp、tomcat、IIS等其它Web服务器的压力。
ab命令对发出负载的计算机要求很低,它既不会占用很高CPU,也不会占用很多内存。但却会给目标服务器造成巨大的负载,其原理类似CC攻击。自己测试使用也需要注意,否则一次上太多的负载。可能造成目标服务器资源耗完,严重时甚至导致死机。
ab的安装
不同版本的指令不同
ubuntu:
apt install apache2-utils -y
centos:
yum -y install httpd-tools
# 安装依赖 yum-utils中的yumdownload 工具
# 如果没有找到 yumdownload 命令可以
yum install yum-utils
测试安装是否成功:ab -V
[root@vic html]# ab -V
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/
ab参数说明
有关ab命令的使用,我们可以通过帮助命令进行查看。如下:
[root@vic html]# ab --help
ab: wrong number of arguments
Usage: ab [options] [http[s]://]hostname[:port]/pathOptions are:
-n requests Number of requests to perform
-c concurrency Number of multiple requests to make at a time
-t timelimit Seconds to max. to spend on benchmarking
This implies -n 50000
-s timeout Seconds to max. wait for each response
Default is 30 seconds
-b windowsize Size of TCP send/receive buffer, in bytes
-B address Address to bind to when making outgoing connections
-p postfile File containing data to POST. Remember also to set -T
-u putfile File containing data to PUT. Remember also to set -T
-T content-type Content-type header to use for POST/PUT data, eg.
'application/x-www-form-urlencoded'
Default is 'text/plain'
-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 Add cookie, eg. 'Apache=1234'. (repeatable)
-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.
-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.
-q Do not show progress when doing more than 150 requests
-l Accept variable document length (use this for dynamic pages)
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-r Don't exit on socket receive errors.
-m method Method name
-h Display usage information (this message)
-I Disable TLS Server Name Indication (SNI) extension
-Z ciphersuite Specify SSL/TLS cipher suite (See openssl ciphers)
-f protocol Specify SSL/TLS protocol
(SSL2, TLS1, TLS1.1, TLS1.2 or ALL)
-E certfile Specify optional client certificate chain and private key
下面我们对这些参数,进行相关说明。如下:
- -n即requests:在测试会话中所执行的请求个数,默认时,仅执行一个请求。即requests,用于指定压力测试总共的执行次数。
- -c:一次产生的请求个数,默认是一次一个。即concurrency,用于指定的并发数。
- -t:测试所进行的最大秒数。其内部隐含值是-n 50000,它可以使对服务器的测试限制在一个固定的总时间以内。默认时,没有时间限制。即timelimit,等待响应的最大时间(单位:秒)。
- -b 即windowsize:TCP发送/接收的缓冲大小(单位:字节)。
- -p即postfile:发送POST请求时需要上传的文件,此外还必须设置-T参数。
- -u 即putfile:发送PUT请求时需要上传的文件,此外还必须设置-T参数。
- -T :即content-type,用于设置Content-Type请求头信息,例如:application/x-www-form-urlencoded,默认值为text/plain。
- -v:设置显示信息的详细程度-4或更大值会显示头信息,3或更大值可以显示响应代码(404,200等),2或更大值可以显示警告和其他信息。
- -w:以HTML表的格式输出结果。默认时,它是白色背景的两列宽度的一张表。
- -i:执行HEAD请求,而不是GET。
- -x:设置
<table>
属性的字符串。 - -y:设置
<tr>
属性的字符串。 - -z 设置字符串作为
td
标签的属性。 - -C:对请求附加一个Cookie:行。其典型形式是name=value的一个参数对,此参数可以重复。
- -H:对请求附加额外的头信息。此参数的典型形式是一个有效的头信息行,其中包含了以冒号分隔的字段和值的对(如,“Accept-Encoding:zip/zop;8bit”)。
- -A:对服务器提供BASIC认证信任。用户名和密码由一个:隔开,并以base64编码形式发送。无论服务器是否需要(即,是否发送了401认证需求代码),此字符串都会被发送。
- -P:对一个中转代理提供BASIC认证信任。用户名和密码由一个:隔开,并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码),此字符串都会被发送。
- -X:对请求使用代理服务器。指定使用的和端口号,例如:“126.10.10.3:88”。
- -V:显示版本号并退出。
- -k:启用HTTP KeepAlive功能,即在一个HTTP会话中执行多个请求。默认时,不启用KeepAlive功能。
- -h:显示使用方法。
- -d:不显示"percentage served within XX [ms] table"的消息(为以前的版本提供支持)。不显示百分比。
- -S 不显示预估和警告信息。
- -e:产生一个以逗号分隔的(CSV)文件,其中包含了处理每个相应百分比的请求所需要(从1%到100%)的相应百分比的(以微妙为单位)时间。由于这种格式已经“二进制化”,所以比’gnuplot’格式更有用。
- -g:把所有测试结果写入一个’gnuplot’或者TSV(以Tab分隔的)文件。此文件可以方便地导入到Gnuplot,IDL,Mathematica,Igor甚至Excel中。其中的第一行为标题。
- -r 指定接收到错误信息时不退出程序。
- -q:如果处理的请求数大于150,ab每处理大约10%或者100个请求时,会在stderr输出一个进度计数。此-q标记可以抑制这些信息。
性能指标
吞吐量(Requests per second)
服务器并发处理能力的量化描述,单位是reqs/s,指的是在某个并发用户数下单位时间内处理的请求数,某个并发用户数下单位时间内能处理的最大请求数,称之为最大吞吐率。
记住:吞吐率是基于并发用户数的。这句话代表了两个含义:
- 吞吐率和并发用户相关
- 不同的并发用户下,吞吐率一般是不同的
计算公式:总请求数/处理完成这些请求数所花费的时间,即
Request per second=Complete requests/Time taken for tests
必须要说明的是,这个数值表示当前机器的整体性能,值越大越好。
并发连接数(The number of concurrent connections)
并发连接数指的是某个时刻服务器所接受的请求数目,简单的讲,就是一个会话。
并发用户数(Concurrency Level)
要注意区分这个概念和并发连接数之间的区别,一个用户可能同时会产生多个会话,也即连接数。在HTTP/1.1下,IE7支持两个并发连接,IE8支持6个并发连接,FireFox3支持4个并发连接,所以相应的,我们的并发用户数就得除以这个基数。
用户平均请求等待时间(Time per request)
计算公式:处理完成所有请求数所花费的时间/(总请求数/并发用户数),即:
Time per request=Time taken for tests/(Complete requests/Concurrency Level)
服务器平均请求等待时间(Time per request:across all concurrent requests)
计算公式:处理完成所有请求数所花费的时间/总请求数,即:
Time taken for/testsComplete requests
可以看到,它是吞吐率的倒数。
同时,它也等于用户平均请求等待时间/并发用户数,即
Time per request/Concurrency Level
ab的应用(get请求)
ab的命令参数比较多,我们经常使用的是-c和-n参数。
ab -n 1000 -c 100 http://www.baidu.com/
- -c100表示并发用户数为100,每次并发100个
- -n1000表示请求总数为1000,共发送1000个请求
[root@vic html]# ab -c 10 -n 100 http://www.myvick.cn/index.php
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.myvick.cn (be patient).....done
Server Software: nginx/1.13.6 #测试服务器的名字
Server Hostname: www.myvick.cn #请求的URL主机名
Server Port: 80 #web服务器监听的端口
Document Path: /index.php #请求的URL中的根绝对路径,通过该文件的后缀名,我们一般可以了解该请求的类型
Document Length: 799 bytes #HTTP响应数据的正文长度
Concurrency Level: 10 # 并发用户数,这是我们设置的参数之一
Time taken for tests: 0.668 seconds #所有这些请求被处理完成所花费的总时间 单位秒
Complete requests: 100 # 总请求数量,这是我们设置的参数之一
Failed requests: 0 # 表示失败的请求数量,这里的失败是指请求在连接服务器、发送数据等环节发生异常,以及无响应后超时的情况
Write errors: 0
Total transferred: 96200 bytes #所有请求的响应数据长度总和。包括每个HTTP响应数据的头信息和正文数据的长度
HTML transferred: 79900 bytes # 所有请求的响应数据中正文数据的总和,也就是减去了Total transferred中HTTP响应数据中的头信息的长度
Requests per second: 149.71 [#/sec] (mean) #吞吐率,计算公式:Complete requests/Time taken for tests 总请求数/处理完成这些请求数所花费的时间
Time per request: 66.797 [ms] (mean) # 用户平均请求等待时间,计算公式:Time token for tests/(Complete requests/Concurrency Level)。处理完成所有请求数所花费的时间/(总请求数/并发用户数)
Time per request: 6.680 [ms] (mean, across all concurrent requests) #服务器平均请求等待时间,计算公式:Time taken for tests/Complete requests,正好是吞吐率的倒数。也可以这么统计:Time per request/Concurrency Level
Transfer rate: 140.64 [Kbytes/sec] received #表示这些请求在单位时间内从服务器获取的数据长度,计算公式:Total trnasferred/ Time taken for tests,这个统计很好的说明服务器的处理能力达到极限时,其出口宽带的需求量。
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 5
Processing: 2 26 81.3 3 615
Waiting: 1 26 81.3 3 615
Total: 3 28 81.3 6 618
Percentage of the requests served within a certain time (ms)
50% 6
66% 6
75% 7
80% 7
90% 10
95% 209
98% 209
99% 618
100% 618 (longest request)
#Percentage of requests served within a certain time(ms)这部分数据用于描述每个请求处理时间的分布情况,比如以上测试,80%的请求处理时间都不超过7ms,这个处理时间是指前面的Time per request,即对于单个用户而言,平均每个请求的处理时间
ab的应用(Post请求)
- 新建一个文件,里面放入POST参数。
注意,这个承载POST参数的文件,不依赖于后缀名。可跨平台(比如 Linux 下用 vi 建立的文件,win下也可以用)
POST文本内容如下:
name=chang&password=11111ok
我把这个文本保存成 postdata.txt ,放到了win机器下的 F盘 下。
- 使用ab命令
ab -n 1 -c 1 -p f:/postdata.txt -T application/x-www-form-urlencoded "http://127.0.0.1/abpost"
注意,最后的 URL 需要加引号。
结果分析
服务器信息
- Server Software:表示被测试的Web服务器软件名称。
- Server Hostname:表示请求的URL主机名。
- Server Port表示:被测试的Web服务器软件的监听端口。
服务域名是www.myvick.cn,端口号80端口。
Server Software: nginx/1.13.6 #测试服务器的名字
Server Hostname: www.myvick.cn #请求的URL主机名
Server Port: 80 #web服务器监听的端口
文档信息
- Document Path:表示请求的URL中的根绝对路径,通过该文件的后缀名,我们一般可以了解该请求的类型。
- Document Length:表示HTTP响应数据的正文长度。
文档路径/index.php ,文档长度799 字节(http相应的正文长度)。
Document Path: /index.php #请求的URL中的根绝对路径,通过该文件的后缀名,我们一般可以了解该请求的类型
Document Length: 799 bytes #HTTP响应数据的正文长度
重要指标
- Concurrency Level:表示并发用户数,这是我们设置的参数之一。
- Time taken for tests:表示所有这些请求被处理完成所花费的总时间。
- Complete requests:表示总请求数量,这是我们设置的参数之一。
- Failed requests:表示失败的请求数量,这里的失败是指请求在连接服务器、发送数据等环节发生异常,以及无响应后超时的情况。如果接收到的HTTP响应数据的头信息中含有2XX以外的状态码,则会在测试结果中显示另一个名为“Non-2xx responses”的统计项,用于统计这部分请求数,这些请求并不算在失败的请求中。
- Total transferred:表示所有请求的响应数据长度总和,包括每个HTTP响应数据的头信息和正文数据的长度。注意这里不包括HTTP请求数据的长度,仅仅为web服务器流向用户PC的应用层数据总长度。
- HTML transferred:表示所有请求的响应数据中正文数据的总和,也就是减去了Total transferred中HTTP响应数据中的头信息的长度。
Concurrency Level: 10 # 并发用户数,这是我们设置的参数之一
Time taken for tests: 0.668 seconds #所有这些请求被处理完成所花费的总时间 单位秒
Complete requests: 100 # 总请求数量,这是我们设置的参数之一
Failed requests: 0 # 表示失败的请求数量,这里的失败是指请求在连接服务器、发送数据等环节发生异常,以及无响应后超时的情况
Write errors: 0
Total transferred: 96200 bytes #所有请求的响应数据长度总和。包括每个HTTP响应数据的头信息和正文数据的长度
HTML transferred: 79900 bytes # 所有请求的响应数据中正文数据的总和,也就是减去了Total transferred中HTTP响应数据中的头信息的长度
- Requests per second: 表示吞吐率(大家最关心的指标之一),详情上述。
- Time per request: 用户平均请求等待时间,计算公式:Time token for tests/(Complete requests/Concurrency Level)。处理完成所有请求数所花费的时间/(总请求数/并发用户数)
- Time per request: 服务器平均请求等待时间
- Transfer rate: 表示这些请求在单位时间内从服务器获取的数据长度
Requests per second: 149.71 [#/sec] (mean) #吞吐率,计算公式:Complete requests/Time taken for tests 总请求数/处理完成这些请求数所花费的时间
Time per request: 66.797 [ms] (mean) # 用户平均请求等待时间,计算公式:Time token for tests/(Complete requests/Concurrency Level)。处理完成所有请求数所花费的时间/(总请求数/并发用户数)
Time per request: 6.680 [ms] (mean, across all concurrent requests) #服务器平均请求等待时间,计算公式:Time taken for tests/Complete requests,正好是吞吐率的倒数。也可以这么统计:Time per request/Concurrency Level
Transfer rate: 140.64 [Kbytes/sec] received #表示这些请求在单位时间内从服务器获取的数据长度,计算公式:Total trnasferred/ Time taken for tests,这个统计很好的说明服务器的处理能力达到极限时,其出口宽带的需求量。
网络上消耗的时间的分解
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 5
Processing: 2 26 81.3 3 615
Waiting: 1 26 81.3 3 615
Total: 3 28 81.3 6 618
这几行组成的表格主要是针对响应时间也就是第一个Time per request进行细分和统计。一个请求的响应时间可以分成网络链接(Connect),系统处理(Processing)和等待(Waiting)三个部分。表中min表示最小值; mean表示平均值;[+/-sd]表示标准差(Standard Deviation) ,也称均方差(mean square error),这个概念在中学的数学课上学过,表示数据的离散程度,数值越大表示数据越分散,系统响应时间越不稳定。 median表示中位数; max当然就是表示最大值了。
需要注意的是表中的Total并不等于前三行数据相加,因为前三行的数据并不是在同一个请求中采集到的,可能某个请求的网络延迟最短,但是系统处理时间又是最长的呢。所以Total是从整个请求所需要的时间的角度来统计的。这里可以看到最慢的一个请求花费了2ms(即100% 2 (longest request))。
每个请求处理时间的分布情况,50%的处理时间在512ms内,66%的处理时间在603ms内…,重要的是看90%的处理时间:
Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 1
90% 1
95% 1
98% 2
99% 2
100% 18 (longest request)