Jmeter-性能测试理论（12）

一.性能测试（非功能测试）
软件性能定义：是指软件的一种非功能特性，并非关注它是否能够完成特定的功能，而是在完成功能时展示出来的及时性。
性能测试定义：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件下对系统各项性能指标进行测试。
性能测试目的：验证软件系统是否能够达到用户提出的性能指标，发现系统中存在的性能瓶颈并加以优化。

二.性能测试相关专业术语
1.负载：模拟业务操作对服务器造成压力的过程，比如模拟1000个用户支付。
2. 基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数据做为基础参考
3.负载测试Load Test:是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项
或多项性能指标达到安全临界值，例如某种资源已经达到泡和状态等。

3. 压力测试 Stress Test:压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于
   系统在峰值负载或超出最大负荷情况下的处理能力（响应时间延长）
4. 稳定性测试：在给系统加载一定业务压力的债况下，使系统运行一段时间，以此检测系统是否稳
   定·（7x24H，一般1x4.8H）
5. 并发测试：测试多个用户同时访问网一个应用、同一个模块或者数据记录时是否存在死锁或者其
   它性能问题。

三.性能测试应用场景：能力验证、规划能力、性能调优、缺陷发现、性能基准比较

性能测试与方法

- 性能指标分类
系统指标（与用户场景和需求相关指标）
资源指标（与硬件资源消耗相关指标）

• 系统指数说明
  1. 响应时间、平均响应时间
  响应时间：对一个请求做出响应所需要的时间（包含网络响应时间和应用程序时间）
  平均响应时间:它并不能反应服务器的整体效率，如1000个请求，990个响应时间为1ms，10个响应时间为100ms,因此用百分位数表示；
  百分位数：以响应时间为例，99%的请求响应时间小于1ms,更能体现整体效率。
  

响应时间和负载的关系：

图中拐点说明：响应时间突然增加意味着系统的一种或多种资源利用达到极限（通常可以利用拐点来进行性能测试分析与定位）。

2.并发用户数
并发主要是针对服务器而言，在同一时刻与服务器进行交互（指向服务器发出请求)的在线用户数。
并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可能是同一个场景或功能，也
可以是不同场景或功能。
在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求
系统用户数：系统注册的总用户数据
三者之间的关系：系统用户数＞－在线用户数＞－并发用户数

并发用户数C,计算公式c=nL/T —经验公式
n:每天访问系统的用户数
L:在线用户从登陆到退出的时间
T:用户每天使用系统大概多长时间
峰值C1,即最大并发数，计算公式C1-CNC
本次假设业务量=用户量
1)业务量：40万＊80%=32万
2)时间段：24小时＊20%=4. 8小时
3)每小时的业务量：32万／4. 8小时=6. 67万／小时
4)每秒的业务量66700/3600=18. 53笔／秒 即每个user 选代一次的时间：1/18. 53=0. 063秒
5)每人每笔业务的处理时间要求=2秒，2/0. 063=37. 7个user
小结：系统要达到40万的业务访问量，需要38个并发用户持续运行4. 8小时，如果满足则性能测试通过。

吞吐量、吞吐率：衡量网络性能的重要指标
吞吐量:网络传输的数量（处理客户的请求数：客户端——>服务器）
吞吐率：单位时间内成功传输的数据量(服务器——>客户端)
备注：对应交互式应用来说，吞吐量指标反应的是服务器承受的压力，能够说明系统的负载能力。

吞吐量和负载之间关系：吞吐量突然增加意味着系统的一种或多种资源利用达到极限（通常可以利用拐点来进行性能测试分析与定位）。

4.事务:TPS（transaction per secnd）、QPS（query per seconds）
事务：可以看作是一个动作（接口）或一系列动作（流程）的集合。
TPS：衡量系统处理事务或教育的能力，每秒处理的事务数
QPS:服务器每秒处理了多少给请求
QPS(TPS)=并发数/平均响应时间
一个系统吞吐量通常有QPS(TPS)、并发数两个因素决定，每套系统这两个至都有一个相对极限值；在应用场景访问压力下，只要有一项达到最高值，且继续增加压力，则系统的吞吐量就会下降（因为超负荷、内存消耗等导致系统性能下降）。

5.点击量、点击率（Bits Per Second)
点击量：指Web Server收到的HTTP请求数。
点击率：单位时间每秒用户向 web Server提交的HTTP请求数。
区分鼠标点击数：如请求一一个网页，网页含有3张图片，向Web Server请求的点击数：1+3=4,而
根标的一次点击效可以访问网页，点击数只有1次
6.PV和UV
PV:访问一个URL,产生一个PV(PageV1ew,页面访问里），每日每个网站的总PV重是形容一个网
站规模的重要指标。
UV:作为一个独立的用户，访问站点的所有页面均算作一个UV(Unique Visitor,用户访问）

• 资源指标
  1.硬件性能指标－资源占用率：指的是对不同系统资源的使用程度，通常以占用最大值的百分比来衡
  量Utilization
  通常需要关注的服务器资源如下：
  CPU·内存Memory,磁盘I/0(Disk1/O),网络I/0(Network 1/O)
  

CPU:主要解释计算机指令以及处理计算机软件中的数据

Linux系统中top命令查看CFU的使用率
CPU的利用率（＜＝75%)有：user(用户使用》，sys(系统调用＜＝30%),wait(等待＜＝5%），idle
（空闲）
当user消耗高时，通过top命令查看哪个用户进程占用cpu的使用
user 消耗过高的原因可能有：
（1)代码问题。如代码中耗时循环中不加s1eep,即例如while的死循环中，没有加sleep时间，
导致没有空余的时间将cpu的控制权给其他的进程，一直陷入该死循环中，cpu得不到休息，所以user
的消耗过高，则cpu的消耗高
（2)gc频繁。gc则为垃圾回收，由于垃圾田收也是需要大里的计算，也消耗cpu,所以当gc频繁
时也导致usx用户空间的消耗也过高，cpu消耗过高

- 最佳并发用户数
如何理解最佳并发用户数和最大并发用户数
性能测试－一理发店模型
所谓的理发店模式，简单地阐过一下，一个理发店有3个理发师，当同时来理发店的客户有3个的时候，那么理发师的资源能够有效地利用，这时3个用户数即为最佳的并发用户数：当理发店未了9个客户的时候，3个客户理发，面6个用户在等待，3个客户的等待时间为1个小时，另外的3个客户的等待时间为2小时，客户的最大忍受时间为3小时包括理发的1个小时，所以6个客户的等待时间都在客户的可以承受范围内，故9个客户是该理发店的最大并发用户数。具体的随着并发用户数的增加，响应时间，吞吐里，资源利用情况如下图所示：
【个人理解】：最佳并发用户数是指资源利用率达到最大；最大峰值是指吞吐量达到最大；最大并非用户数是指响应时间达到最大

最佳并发用户数：当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待
最大并发用户数：系统的负载一直持续，有些用户在处理而有的用户在自己最大的等待时间内等待的时候
我们需要保证的是：
（1)最佳并家用户数需大于系统的平均负载
（2)系统的最大并发用户数要大于系统需要承受的峰值负载
怎么理解这两句话呢？
（1)系统的平均负载：在特定的时间内，系统正在处理的用户数和等待处理的用户数的总和，如果系统的平均负载大于最佳并发用户数，则用户的满意度会下障，所以我们需要保证系统的平均负载小于或者等于最佳并发用户数
（2)峰值：指的是系统的最大能承受的用户数的极值。只有最大并发用户数的大于系统所能承受的峰值负载，才不会造成等待空间资源的浪费，导致系统的效率低下。

四.测试环境准备
a)系统运行环境：这个通常就是我们的测试环境，有些时候需求比较多，做性能测试担心把环境搞垮了影响其它的功能测试，可能需要重新搭建一套专门用来做性能测试的环境。
b)执行机环境：这个就是用来生成负载的执行机，通常需要在物理机上运行，而物理机又是稀缺资源。所以我们每次做性能测试都需要提前准备好执行机环境。

• 测试场景设计：根据性能播求分析来设计符合用户使用习惯的场景，场景设计的好不好直接影响到性能测试的效果。
  3.性能工具准备：
  a)负载工具：根据需求分析和系统特点选择合适的负载工具，比如LR、Jmeter等
  b)需控工具：准备性能测试时的服务器资源、JVM、数据库监控工具，以便进行后续的性能测试分析与调优。
  4.测试自本准备：如果性新测试工具不能满足被测系统的要求或只能满足部分要求时，需要我们自己开发脚本配合工具进行性能别试。

• 测试数据准备：
  a)负载测试数据：并发测试时需要多少数据？比如登录场景？
  b)DB数据量大小：为了尽量符合生产场景，需要模拟线上大量数据情况，那么要往数据库里提前插入一定的数据量。这可能需要花费一些时间，特点是关联系统较多，逻辑复杂的业务可能同时涉及多张表。

• 瓶颈分析与调优
  通过对性能测试结果分析状出系统瓶颈；通过调优优化系统消除系统筑颈。
  日的：使系统运行的更好
  1.一般系统的瓶颈
  性能测试调优需要先发现施强，那么系统一般会存在哪些瓶颈：
  硬件上的性能瓶颈：一般指的是CPU、内存、磁盘1/0方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虚）、服务器操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据摩、web 服务器等）、应用瓶颈（SQL语句、数据库设计、业务逻输、算法等）。
  例如：确定了在服务器数据库上需要6个CPU、12GB内存，但是在测试时发现，CPU的持续利用率超过95%,这时可以认为在硬件上出现了性能瓶强。
  应用软件上的性能瓶颈：
  一般指的是应用服务器、web服务器等应用软件，还包括数据库系统。
  例如：在weblogic平台上配置了JDBC连接池的参数，最大连擦数为50,最小连擦数为5,增加量为10·测试时发现，当负载增加时，现有的连接数不足，系统会动态生成10个新的连接，导致交易处理的响应时间大大增加。这时可以认为在应用软件上出现了性能瓶颈。
  应用程序上的性能瓶颈：
  一般指的是开发人员新开发出来的应用程序。
  例如：程序员开发了一个缴费处理程序，在测试时发现，这个缴责处理程序在处理用户并发缴费请求时，只能串行处理，无法并行处理，导致缴费处理响应时间丰常长，这个可以认为在应用程序上出现了性能瓶颈。
  操作系统上的性能流颈：
  一般指的是windows、UNIX、Linux等操作系统。
  网络设备上的性能瓶颈：
  一般指的是防火墙、动恋负载均衡器、交换机等设备。
  例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶强。

查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈－－－＞网络瓶颈（对局域网，可以不考虑）－－－＞服务器操作系统瓶颈（参数配置）－－－＞中间件瓶颈（参数配置，数据库，web服务器等》－－－＞应用瓶颈（SOL语句、数据库设计、业务逻辑、算法等）
注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据里）下，系统的硬件瓶颈在哪儿就够了。

2.性能调优
一般性能问题调优的步骤：
步骤一：确定问题
应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。
数据原配置：经常引起整个系统运行缓慢，一些诸如oracle的大型数据库都是需要DBA进行正确的参数调整才能投产的。
操作系统配置；不合理就可能引起系统瓶颈。
硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。
网络：网络负载过重导致网络冲突和网络延迟。
步骤二：确定原因
当确定了问题之后，我们要明确这个问题影响的是响应时间吞吐里，还是其他问题？是多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户的操作有什么不用？系统资源监控的结果是否正常？CPU的使用是否到达松限？I/0情况如何？问题是否集中在某一类模块中？是客户端还是服务器出现问题？系统硬件配置是否够用？实际负载是否超过了系统的负载能力？是否未对系统进行优化？通过这整分析及一些与系统相关的问题，可以对系统瓶颈有更深入的了解，进而分析出真正的原因。
步骤三：确定调整目标和解决方案
提高系统吞吐里，缩短响应时间，更好地支持并发。
步骤四：测试解决方案
对通过解决方案调优后的系统进行基准测试。《基准到试是指通过设计科学的别试方法、测试工具和测试系统，实现对一类别试对象的某项性能指标进行定量的和可对比的测试）
步骤五：分析调优结果
系统调优是否达到或者超出了预定目标？系统是整体性能得到7改善，还是以系统某部分性能来解决其他问题。调优是否可以结束了。最后，如果达到了预期目标，调优工作就基本可以结束了。
性能调优要点：
要点1:在应用系统的设计开发过程中，应始终把性新放在考虑的范围内。
要点2:确定清晰明确的性能目标是关键。
要点3:必须保证调优后的程序运行正确。
要点4:系统的性能更大程度上联决于良好的设计，调优技巧只是一个辅助手段。
要点5:调优过程是选代渐进的过程，每一次调优的结果都要反演到后续的代码开发中去。
要点6:性能调优不能以牺牲代码的可读性和可维护性为代价。
对通过解决方案调优后的系统进行基准测试。《基准到试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类别试对象的某项性能指标进行定量的和可对比的测试）