性能分析

不合标准的应用程序性能会产生软件或网络问题。为确保软件满足或超过设计的期望值，有必要分析应用程序的性能以发现潜在的问题。这个过程被称为“性能分析”。它包括检查应用程序以确保每个组件有效地工作，并根据设计密切注视处理器的使用、网络和系统服务、存储和输入/输出(I/O)。

响应时间的2/5/8原则

• 2秒钟之内响应用户是非常好的。

• 2-5秒钟之内响应用户是可以接受的。

• 5-8秒钟是用户能接受的响应的上限。

• >8秒钟是比较糟糕的，用户会选择离开这个Web站点或发起第二次请求。

Bug分布的2/8原则

80%的bug分布在20%的模块里

业务分布的2/8原则

80%的业务量在20%的时间里完成

如何理解，下面我们来个例子吧

用户登录场景：早高峰时段，8：50---9：10，5000坐席上线登陆。

•     业务量：5000个 

•     时间：20x60=1200秒

•     吞吐量=80%x业务量/(20%*时间)=4000/240=16.7/秒

而并非5000/1200=4.1/秒

实际上，登录请求数分布是一个正态分布，最高峰时肯定比4.1/秒更高，高峰段实际上完成了80%的业务量，却只花了20%的时间。

温馨提示：

1. 二八原则计算的结果并非在线并发用户数，是系统要达到的处理能力（吞吐量），初学者容易被误导，那这这个数据就去设置并发数，这是错误滴。

2. 如果你的系统性能要求更高，也可以选择一九原则或更严格的算法，二八原则比较通用，一般系统性能比较接近这个算法而已，大家应该活用。

理发店模型

模型假设

在这个理发店中，事先做如下的假设：

1. 理发店共有3名理发师

2. 每位理发师剪一个头发的时间都是1小时

3. 顾客们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，我们的顾客会立马生气的走人

场景构建

场景1

理发店内只有1位顾客 

有1名理发师为他提供服务，另外2位等着或打杂帮忙。1小时后，两位顾客剪完头发出门 在这1个小时里，整个理发店只服务了1位顾客，这位顾客花费在这次剪发的时间是1小时。

理发店内同时有2位顾客

同时有2名理发师在为顾客服务，另外1位等着或打杂帮忙。1小时后，两位顾客剪完头发出门 在这1小时里，整个理发店服务了两位顾客，这两位顾客花费在剪发的时间均为1小时

理发店内同时有3位顾客

同时有3名理发师在为顾客服务。1小时后，三位顾客剪完头发出门

在这1小时里，整个理发店服务了三位顾客，这三位顾客花费在剪发的时间均为1小时

场景总结：
在理发店同时服务的顾客数量从1位增加到3位的过程中，随着顾客数量的增多，理发店的整体工作效率在提高，而且每位顾客在理发店内所呆的时间并未延长。

当然，可以假设当只有1位顾客和2位顾客时，空闲的理发师可以帮忙打杂，使得其他理发师的工作效率提高，并使每位顾客的剪发时间小于1小时 不过即使根据这个假设，虽然随着顾客数量的增多，每位顾客的服务时间有所延长，但是这个时间始终还被控制在顾客可接受的范围之内，并且顾客是不需要等待的。

场景2

随着理发店的生意越来越好，顾客也越来越多，出现新的场景

假设有一次顾客A、B、C刚进理发店准备剪发，外面一推门又进来了顾客D、E、F

因为A、B、C三位顾客先到，所以D、E、F三位只好坐在长板凳上等着

1小时后，A、B、C三位剪完头发走了，他们每个人这次剪发所花费的时间均为1小时。可是D、E、F三位就没有这么好运，因为他们要先等A、B、C三位剪完才能剪，所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时和剪发1小时。

通过上面这个场景我们可以发现，对于理发店来说，都是每小时服务三位顾客——第1个小时是A、B、C，第二个小时是D、E、F；但是对于顾客D、E、F来说，“响应时间”延长了。

场景3

假设这次理发店里一次来了9位顾客，这9位顾客中有3位的“响应时间”为1小时，有3位的“响应时间”为2小时（等待1小时+剪发1小时），还有3位的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了。（其实这种场景在我们生活中也是非常常见的一种情况）

上面的场景如何与性能测试挂钩呢？

性能测试曲线模型是一条随着测试时间不断变化的曲线，与服务器资源，用户数或其他的性能指标密切相关的曲线。

　　一般的性能测试曲线图主要分为三个区域，分别是：

• light load（轻压力区）

• heavy load（重压力区）

• Buckle Zone

　　图中的三条曲线，分别代表：

• Utilization（资源利用率，指软硬件资源）

• Throughput（吞吐量，即单位时间内处理请求的数量）

• Response Time（响应时间）

　　图中坐标轴的横轴从左到右表示并发用户数（Number of Concurrent Users）的不断增长。

分析：

　　资源利用率在第一区域稳定增长，在第二区域小幅增长，在第三区域呈直线，表示饱和。

　　响应时间随着并发用户数的增加，在前两个区域基本平稳，小幅递增，在第三个区域急速递增，产生拐点。

　　同时，吞吐量随着并发用户数的增加，请求增加，在第一区域基本稳定上升，在第二区域处理达到顶点，随后开始下降。

　　当系统的负载等于最佳并发用户数时，整体效率最高，也没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大用户并发数之间时，系统可以继续工作但用户的等待时间延长；当系统负载大于最大并发用户数时，用户满意度基本为零，甚至放弃访问。

根据区域交界处，又衍生两个概念：

• 最佳并发用户数

The Optimum Number of Concurrent Users

Light Load和Heavy Load 两个区域交界处的并发用户数

• 最大并发用户数

The Maximum Number of Concurrent Users

Heavy Load和Buckle Zone两个区域交界处的并发用户数

性能拐点

1、对一个基本的请求做并发测试，看是否能达到tps=1000，或者找到tps拐点。

2、设置线程数为1，循环数为1，查看Throught为多少（假如是170），计算下如果想要达到1000的话大概需要多少线程数，1000/170，大约为6。

3、将线程数设置为6，对请求加一个Throught shaping timer ，设置如下：

 4、将Tracactions per second的颗粒度调低点（settings）

5、运行，查看tps

性能测试行业常用的性能指标表示法

响应时间(RT response time)

　　对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。

吞吐量(Throughput)

      吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。

　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。

并发用户数

　　并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。

QPS每秒查询率(Query Per Second)

　　每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。（看来是类似于TPS，只是应用于特定场景的吞吐量）

TPS每秒执行的事务数量(throughput per second)

      TPS (transaction per second)代表每秒执行的事务数量，可基于测试周期内完成的事务数量计算得出。例如，用户每分钟执行6个事务，TPS为6 / 60s = 0.10 TPS。同时我们会知道事务的响应时间(或节拍)，以此例，60秒完成6个事务也同时代表每个事务的响应时间或节拍为10秒。

估算QPS峰值

原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间。
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器 。

每天300w PV 的在单台机器上，这台机器需要多少QPS？
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。
故该机器支持139QPS即可。

并发数

首先，理解三个用户数的概念：

系统用户数、在线用户数、并发用户数

系统用户数就是一个系统中所有的注册用户数。eg. 当前微信中的所有注册用户数；在线用户数是当前登录系统的用户数，eg.当前登录微信的总用户数 （均为在线状态，不管该用户做什么操作）；并发用户数是指对Server产生压力的用户数，eg.当前微信所有登录用户中，正在进行操作的用户数（仅指对Server产生压力的操作）

我们测试时仅关注并发用户数，一般，需求采集人员会将线上的并发用户数根据日志或工具分析统计出。测试时，要以性能测试需求为准，此外，并发操作也包含多种情况 ，如所有用户同时进行购买或支付操作；或多个用户同时发出多个不同请求，如加入购物车、删除商品、增减数量、支付、退款等操作。

响应时间

先看一个请求从发出到用户看到结果的过程：用户发送一个请求后，通过网络传输、DNS解析等步骤到达Server端后，Server通过各种算法处理，将结果通过网络传输返回到Client，Client要经过解析渲染等步骤，最后才呈现给用户。

通过以上流程可知，响应时间的计算模式：响应时间=请求传输时间+Server处理时间+响应传输时间+前端解析渲染时间。

由此可见，在工作中，一方面响应时间要根据不同业务及用户的具体要求而定；另一方面分析结果时要注意当前的业务模型（如前端性能测试与服务器性能测试）

资源利用率

关于资源利用率初期了解以下几个重要指标即可：

CPU

对于CPU都不陌生，简言之，是用来处理＼判断事务的，CPU一般有系统CPU与用户CPU，前者是 处理系统占用的资源 ；而后者是处理应用程序占用的资源 。

网络

即网络传输的流量，测试过程中对网络的监控以，以分析是否存在瓶颈。

IO

即，Input/Output，输入/输出。关注与磁盘的交互频率等

内存

即数据存储区域。一般读数据时从内存中读取要比硬盘读取快很多 ，但需要关注的是内存溢出或内存泄漏问题。

队列

属于数据结构的概念了 ，是一种线性表，可以在队列前删除，在队尾处进行插入。测试过程中，如果发现队列越来越长，很可能会发生阻塞问题。