性能测试

性能测试介绍

指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试

对性能的认识

---从用户的角度：

---从开发的角度：

---从系统管理员的角度：

性能测试意义

        研究表明，对于Web网站，多1秒的页面延迟相当于少了11%的PV，相当于降低了16%的顾客满意度。这就意味着：如果一个网站每天挣10万元，那么一年下来，由于页面加载速度慢1秒，可能导致损失25万元的销售额 ; Compuware公司分析了超过150个网站和150万个浏览页面，发现页面响应时间从2秒增到10秒，会导致38%的浏览放弃率 。随着各个企业的业务发展、用户访问量的增加，其服务系统承载的负荷也会随着增加，系统性能的好坏将严重影响企业的利益，因此对于性能测试与优化也越来越受业界的重视。

性能测试类型

基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数做为基础参考

负载测试：是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等 。

压力测试：压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。

稳定性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。

并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题

性能测试基本概念

响应时间

1.定义：从用户发送一个请求到用户接收到服务器返回的响应数据这段时间就是响应时间

2.关键路径：下图为一次http请求经过的路径，请求会经过网络发送到web服务器进行处理，如果需要操作DB，再由网络转发到数据库进行处理，然后返回值给web服务器，web服务器最后把结果数据通过网络返回给客户端

3.计算方法：Response time = (N1+N2+N3+N4)+ (A1+A2+a3)，即：（网络时间 + 应用程序处理时间）

4.响应时间-负载对应关系：

图中拐点说明：

（1）响应时间突然增加

（2）意味着系统的一种或多种资源利用达到的极限

（3）通常可以利用拐点来进行性能测试分析与定位

吞吐量

1.定义：单位时间内系统处理的客户端请求的数量

2.计算单位：一般使用请求数／秒做为吞吐量的单位，也可以使用页面数／秒表表示。 另外，从业务角度来说也可以使用 访问人数 /天 或 页面访问量／天 做为单位。

3.计算方法：Throughput = (number of requests) / (total time).

4.吞吐量-负载对应关系： 

图中拐点说明：

（1）吞吐量逐渐达到饱和

（2）意味着系统的一种或多种资源利用达到的极限

（3）通常可以利用拐点来进行性能测试分析与定位

并发数

（1）并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可能是同一个场景或功能，也可以是不同场景或功能。

（2）在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求

（3）系统用户数：系统注册的总用户数据

三者之间的关系：系统用户数 >= 在线用户数 >= 并发用户数

并发，QPS，响应时间，三者之间重要的关系

QPS*T(s)约等于并发，约等于含义是在同数量级上

错误率

错误：一般就是实际的响应数据不是期望得到的响应数据

错误一般分为，请求异常(接口或环境问题)，业务异常(代码或数据问题)

PV/UV

PV：Page View，访问一个页面，产生一个PV

UV：Unique Visitor，一个用户访问网站，产生一个UV

备注：1.每日每个网站的总PV量是形容一个网站规模的重要指标

           2.作为一个独立的用户，访问站点的所有页面均算作一个UV

容量评估的公式：

第一步：先根据日活用户数，计算所需的tps

计算原则：1.20%的高峰时间内完成80%的日活用户数的请求

                  2.为了降低风险，一般设定的目标是评估值的3-5倍

目标tps的计算：

(日活用户数*每个用户在系统中产生的请求数*0.8)/(时间段*3600*0.2)*5

第二步：压测现有系统的实际性能

结合目标tps与现有系统的实际tps，即可估算整个系统所需要的服务器数目

例：用户系统目标tps-1000，现有的压测结果是，单台服务器用户模块的整体qps-500，故用户模块要想维持目标日活需要至少2台服务器

资源利用率

1.定义：指的是对不同系统资源的使用程度，通常以占用最大值的百分比来衡量

2.通常需要关注的服务器资源如下：

（1）CPU：就像人的大脑，主要负责相关事情的判断以及实际处理的机制

（2）内存：大脑中的记忆块区，将眼睛，皮肤等收集到的信息记录起来的地方，以供cpu进行判断，但是是临时的，访问速度快，如果关机或断电这里的数据会消失。

（3）磁盘IO：大脑中的记忆区块，将重要的数据保存起来（永久保存，关机或断电不会丢失，速度慢），以便将来再次使用这些数据。

（4）网络/带宽：单位时间内从网络中的某一点到另一点所能通过的数据量(BPS)

3. 资源利用-负载对应关系：

图中拐点说明：

（1）服务器某荐资源使用逐渐达到饱和

（2）通常可以利用拐点来进行性能测试分析与定位

命令：sar -u ALL -r -q -d -p -n DEV 2

CPU    all 表示统计信息为所有 CPU 的平均值 

%user 在用户模式运行所使用 CPU百分比 

%nice 在用户模式用于nice操作所使用 CPU百分比 

%system 在系统模式运行所使用 CPU 百分比 

%iowait 用于等待I/O操作所占用 CPU 百分比 

%steal 管理程序为另一个虚拟进程提供服务而等待, 占CPU 百分比

 %idle 空闲CPU占用的百分比

指标

kbmemfree：服务器空闲的内存

kbmemused：服务器使用的内存

%memused：物理内存使用率, 这个值是kbmemused和内存总量(不包括swap)百分比

kbbuffers：块设备(block device)所占用的缓存页，包括直接读写块设备、以及文件系统元数据(metadata)如SuperBlock所使用的缓存页

kbcached：表示普通文件所占用的缓存页

kbcommit：保证当前系统所需要的内存,即为了确保不溢出而需要的内存(RAM+swap).

%commit：这个值是kbcommit与内存总量(包括swap)的一个百分比

runq-sz：运行队列的长度（等待运行的进程数）

plist-sz：进程列表中进程（processes）和线程（threads）的数量

ldavg-1：最后1 分钟的系统平均负载（System load average）

ldavg-5：过去5 分钟的系统平均负载

ldavg-15：过去15 分钟的系统平均负载

DEV ：磁盘设备名称

tps:  每秒到物理磁盘的请求数

rd_sec/s:  每秒从设备读入的扇区数（1扇区=512字节）

wr_sec/s:  每秒写入设备的扇区数目

avgrq-sz:   平均每次设备I/O操作的数据大小（以扇区为单位）

avgqu-sz:   平均I/O队列的长度

await:    从请求磁盘操作到系统完成处理的平均消耗时间,包括请求队列等待时间,单位ms

svctm:   平均每次设备I/O 操作的服务时间（毫秒）

%util:     一秒中有百分之几的时间用用于I/O操作

IFACE： 网络接口设备

rxpck/s： 每秒接收的数据包数目            txpck/s  ： 每秒发送的数据包数目

rxkB/s： 每秒接受的字节数                       txkB/s ：每秒发送的字节数

rxcmp/s： 每秒接受的压缩包数目           txcmp/s ：每秒发送的压缩包数目

rxmcst/s： 每秒接受的多播数据包数目

总结——

1.  us+sy参考值为80%，如果大于80%，说明可能存在CPU资源不足的情况

2.  %util若接近100%，表示磁盘产生I/O请求太多，I/O系统已经满负荷地在工作，该磁盘可能存在瓶颈

3. %memused参考值为98%，如果大于98%，说明可能存在内存不足的情况

4. rxkB/s或txkB/s，如果是百兆网卡，参考值是12MB/s，如果是千兆网卡，参考值为120MB/s，如果是万兆网卡，参考值为1.2GB/s，带宽超过参考值，说明可能存在带宽不足的情况

5. await的大小一般取决与svctm的值和I/O队列长度以及I/O请求模式。如果svctm与await很接近，表示几乎没有I/O等待，磁盘性能很好；如果await的值远高于svctm的值，表示I/O队列等待太长，可能就会导致运行的应用程序变慢，则需要检查程序或更换更快的磁盘

工具

常见的性能测试工具，如：Jmeter, Loadrunner, Apche AB,WRK, unixbench, ubench,iperf,fio,IxChariot等等，每种工具的优缺点各异，目前我们常用的Jmter，上手快，接口测试的各种需求基本都能够满足。

报告

性能测试报告中，既要包含重要性能指标的值，又要包含服务器负载的情况，如下图，所示：

不仅要在报告中记录好本次压测的客户端与服务器端的性能数据，而且还应用在发性能报告的邮件中，明确的写清楚，本次压测的目的，环境，结论，存在的问题，风险等，方便研发，产品，项目的相关人员阅读。

瓶颈

1. 通过基准数据判断性能瓶颈 

基准数据，就是指框架或者中间件的单服务的性能极限，如tomcat框架，在目前思源环境_2C4G_docker下的极限性能QPS_4w左右（apache-tomcat-7.0.85）Mysql的select空查询，在目前思源环境_2C4G_docker下的极限性能QPS_1.8w左右（mysql-5.1.73），Nginx转发能力,在目前思源环境_2C4G_docker下的极限性能QPS_3.6w左右（nginx version: nginx/1.5.9），基准性能数据，为查找性能瓶颈提供一种判断的基准，如，在制定基于tomcat框架的接口性能目标时，其值应该低于4w的qps，才比较合理；测试调用sql查询的接口，如果性能已达1.5w左右，那基本也没有调优空间了；如果有需求nginx转发能力要达到5w，则就要优先考虑框架配置调优。

tomcat框架-2C4Gdocker的基准性能：QPS_4w(apache-tomcat-7.0.85)

http://172.28.34.98:8080/docs/tomcat.html

tomcat框架-2C4Gdocker的基准性能：QPS_4w(apache-tomcat-7.0.85)

http://172.28.34.98:8080/docs/tomcat.html

Mysql的select空查询- 2C4G docker的基准性能:QPS_1.7w

jdbc:mysql://172.28.34.98/jizhuntest test/test(mysql-5.1.73)

Nginx框架-2C4G docker的基准性能：QPS_3.6w (nginx/1.5.9)

http://172.28.34.98:8081/helloword.html

2. 通过服务器资源判断性能瓶颈

CPU使用率99.5%

千兆带宽满

内存不足

磁盘I/O

3. 通过APM协助判断性能瓶颈

具体哪行代码的问题

数据库的SQL语句问题

GC频繁

第三方调用

网络延时问题

jprofile可看到方法的调用层次，cpu热点方法等

总结：

1. 通过框架或者中间件的基准性能数据，可界定性能数据的上线

2. 在定位性能瓶颈前一定要清楚请求的整个链路拓扑，通过监控拓扑各个环节服务器的负载情况，可以进一步的确定到底哪个环节是性能瓶颈

3. 可以借助APM，进行代码级别的定位性能瓶颈的具体原因

4.APM也不是万能的，很多情况下，也是会发生漏监控的情况，所以性能瓶颈的定位也不能够完全依赖APM

其它常用概念

TPS：Transactions Per Second，每秒事务数

思考时间：用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的

点击数：每秒钟用户向WEB服务器提交的HTTP请求数。 这个指标是WEB应用特有的一个指标:WEB应用是”请求-响应”模式,用户发出一次申请,服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。 如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对服务器的压力越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。 需要注意的是，这里的点击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求.

性能测试模型

曲线拐点模型

 

X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。

随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后 进入拐点区后倾斜率增大，响应时间急剧增加。

接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。

同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。

最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发 用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

地铁模型

假设：

某地铁站进站只有3个刷卡机。

人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要1s。

乘客耐心有限，如果等待超过30min，就暴躁、唠叨，甚至放弃。

场景一：只有1名乘客进站时，这名乘客可以在1s的时间内完成进站，且只利用了一台刷卡机，剩余2台等待着。

场景二：只有2名乘客进站时，2名乘客仍都可以在1s的时间内完成进站，且利用了2台刷卡机，剩余1台等待着。

场景三：只有3名乘客进站时，3名乘客还能在1s的时间内完成进站，且利用了3台刷卡机，资源得到充分利用。

场景四：A、B、C三名乘客进站，同时D、E、F乘客也要进站，因为A、B、C先到，所以D、E、F乘客需要排队。

那么，A、B、C乘客进站时间为1s，而D、E、F乘客必须等待1s，所以他们3位在进站的时间是2s。

场景五：假设这次进站一次来了9名乘客，有3名的“响应时间”为1s，有3名的“响应时间”为2s（等待1s+进站1s）， 还有3名的“响应时间”为3s（等待2s+进站1s）。

场景六：如果地铁正好在火车站，每名乘客都拿着大小不同的包，包太大导致卡在刷卡机堵塞，每名乘客的进站时 间就会又不一样。刷卡机有加宽的和正常宽度的两种类型，那么拿大包的乘客可以通过加宽的刷卡机快速进站（增 加带宽）。

场景七：进站的乘客越来越多，3台刷卡机已经无法满足需求，为了减少人流的积压，需要再多开几个刷卡机，增 加进站的人流与速度（提升TPS、增大连接数）。

场景八：到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、 拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是 在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用服务器、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。

备注：以上内容包含网上收集整理以及公司培训内容整理。