性能测试瓶颈分析与系统调优(2)理论知识

2.1 性能需求

学会梳理：性能测试不能脱离实际需求，所以不论哪一种场景，有哪方面的性能需求，我们在执行测试的时候都会涉及到具体的业务场景

产品经理：性能测试的范围，如比竞品快一点，比对的范围，快那几个功能

业务场景：

性能指标：吞吐量，响应时间，并发量

性能测试执行思路：通过接口测试工具，反复对这个接口进行多次测试，取平均响应时间；模拟贴近真实环境的用户数量，并发对这个接口进行测试，取响应平均值；性能用例

2.2 执行性能测试

用例：使用工具模拟10个用户，并发对对接口发起调用（持续2分钟）或者（总发起1000次的调用）判定响应时间是否在3s以内

执行：工具：jmeter，loadrunner，python（locust）工具选型最重要，能否方便快捷的模拟出性能场景

结果采集：很多种，jmeter汇总报告

2.3 性能结果分析

分析性能指标是否达标：查看jmeter测试结果报告

不达标，性能瓶颈分析：定位瓶颈，程序为什么会有瓶颈，哪一个资源不够用或者没用好，怎么做？监控服务器资源使用情况

2.4 用例执行过程

2.4.1基准测试：

场景：线上服务器资源规划，买多少服务器

性能基准：极少的并发去测试每次用户操作需要占用的资源以及性能指标（最新为1，在一个线程下，默认系统不存在瓶颈）

基准测试结果分析：

根据网络吞吐量（接受）如果服务器宽带不能支持每秒传输17M左右的数据，则服务器无法实现270/s吞吐量

1个线程模拟270/s并发，想要模拟4000/s并发，理论需要用到15线程模拟用户

2.4.2负载测试

负载测试测试手法-梯度压测

场景：线上预计会达到4000/s的并发，系统能不能抗住

不断给系统增加系统并发压力，直到系统达不到我们的性能要求,通过关注：相应时间，吞吐量，资源占用率

梯度压测手法：

注意事项：当负责测试的结果和预期结果有出入，调整线程数

吞吐量模型1：理论来说，吞吐量曲线，梯形，随着并发数量的增加，吞吐量逐步增加，并发数量增加到一定程度；吞吐量保持在在一定的值左右，上下来回浮动，继续增加并发数，，吞吐量可能降低，表现为系统处理不过来，开始报错。

吞吐量模型2：随着并发数量的增加，吞吐量逐步增加，并发数量增加到一定程度；吞吐量保持在在一定的值左右，上下来回浮动，继续增加并发数，吞吐量依旧保持在一定的值左右，上下来回浮动，此时，响应时间变长。

吞吐量预期结果

第一阶段：并发增加，吞吐量增加

第二阶段：并发增加，吞吐量不会增加，相应时间边长

第三阶段：增加并发，崩溃

2.4.3基准测试与负载测试的关联

基准测试：收集系统在极低并发场景中的性能基线，基准测试线程数为什么是1，对线程数要求，系统100%能够负载的情况下，1是最小单位

负载测试：目的是为了发现程序系统的实际处理能力，负载测试线程数量，根据基本测试测试里面，每个线程能够在每秒模拟多少此并发。例如：基准测试中1个线程可以模拟器40/s并发，目标：测试系统是否能够承载4000/s的并发，则初步线程数=目标并发/单线程模拟并发数量

2.4.4压力测试

压力测试又称耐久性测试，其目的，测试系统在持续高压的情况下，能够持续稳定运行多长时间，两外一种说法:尖峰测试，浪潮测试

2.5性能测试指标介绍

2.5.1响应应时间

响应时间：一次操作完成的时间，等待+处理

网页响应时间：页面多个子资源加载累计计算

接口相应时间：接口请求，接收响应的完整时间

2.5.2并发量

相对并发：指一段时间内向服务器发出请求的并发，人的操作是有间隔的，业界通常以秒为单位

绝对并发：同一个时间点，服务器收到的请求数量。绝对并是理论的，服务器性能测试一般为相对并发（同一个时间点，向服务器发起请求，服达务器接收的请求时间也是不同的）

2.5.3 吞吐量TPS和QPS

从应用的角度：

QPS每秒查询率（query per second）针对查询类请求处理，每秒能处理多少比

TPS（transaction per second）每秒处理的事务数。涉及到数据变更的操作

网络角度：字节/s

吞吐量：反应程序处理能力综合体现，越大越好

2.5.4 程序性能问题产生原因

任何程序的运行都需要资源，包含：cpu，内存，磁盘，网络

资源不是无限的：例如一个图片请求的操作：

每一个请求后端处理都占用资源，资源不够，程序运行就会受限，

资源占用指标：通常服务器资源保持在85%左右，太低浪费资源，太高有崩溃的风险

2.6性能测试方案

2.6.1性能测试整体流程流程介绍

确认性能需求→编写测试方案→配置测试环境→执行性能测试→分析测试结果→性能优化→回归分析→最终性能报告

2.6.2测试背景

系统的介绍，市场上的类似产品，通过性能测试来评估：系统性能，分析性能变化趋势，分析系统瓶颈风险，帮助规划系统容量，为硬件采购提供建议。务虚，让看不懂的人尽量看懂。

2.6.2测试范围

调研分析：分析用户使用行为；产品经理的帮助；找架构师/技术负责人，提供数据支撑（数据埋点）；性能测试角度思想测试左移；强资源占用行为（上传下载）

2.6.3性能需求分析

业务模型预估（技术负责人认可）：

业务流程节点

数据流程：涉及到表：每天新增多少条

业务量：日均U（用户访问）；日均PV（页面浏览量）

2.6.4性能目标

业务指标：响应时间竞品/产品设计

相对并发两要求：

生产环境数据统计（这个比较准确）

参考自总访问，推导并发量，这里介绍一个2/8原则，20%的时间，贡献了系统80%的访问量；

性能测试主要针对后续会增长的目标量，需要技术负责人和项目经理共同审核

资源占用指标:

通常服务器资源保持在85%左右，太低浪费资源，太高有崩溃的风险

2.6.5 性能测试用例

基准测试：

基准测试能够提供性能指标衡量的一个理论参考依据

例如：并发为1，每秒业务吞吐量100/s，占用网络宽带1M

假设生产服务器的宽带为100M，则业务吞吐量为：100*100=10000/s

一般系统：静态资源和动态资源分开，很多时候，静态资源的测试和动态资源也是分开

负载测试：

线程数=绝对并发，线程：一次请求结束会继续请求，1个线程，在单位时间秒，发起的总请求数=相对并发

手法：梯度压测，例如：模拟器对系统的访问，总线程数2000，初始线程10，每隔5分钟，增加5个线程数，达到2000个线程之后，持续5分钟，然后慢慢停止

压力测试：

通过负载测试找到瓶颈，才能知道系统系统的瓶颈，模拟并发极限数量进行长时间的测试

最大的疑惑：以接口为单独的性能用例设计，还是以流程为用例设计标准：

对于不可拆分的场景，多接口一起测试，最总仍然会针对流程进行性能测试

2.6.6测试策略

执行策略：基准测试开始时间-结束

负载测试开始时间-结束

压力测试开始时间-结束

指标监控测试：业务指标，通过jmeter自带的统计进行查看，jmeter汇总报告，其他插件

资源监控：liunx命令、数据库系统数据、可视化集群监控方案

数据准备：要生成那些数据，怎么生成

2.6.7完成标准

达到上面要求的性能指标

2.6.8风险分析

例如：本次测试由于没有采用与生产环境相同的硬件配置，可能和实际运行的性能有一定的差距

2.6.9术语约定

并发量：模拟业务操作对服务器造成压力的过程，比如模拟100个用户同时进行操作。

负载测试（Load Testing) :

在一定软硬件环境下，通过不断加大负载（不同虚拟用户数）来确定在满足性能指标情况下能够承受的最大用户数。简单说，可以帮我们对系统进行定容定量，找出系统性能的拐点，给予生产环境规划建议。这里的性能指标包括TPS (每秒事务数）、RT (事务平均响应时间）、

压力／强度测试（Stress Testing) : 在一定软硬件环境下，通过高负载的手段来使服务器资源（强调服务器资源，硬件资源）处于极限状态，测试系统在极限状态下长时间运行是否稳定，确定是否稳定的指示包括 TPS、RT、CPU Using, Mem Using等。