性能测试之一：不能不知道的理论篇

性能测试的作用

提供有效的容量规划能力、系统风险识别、系统瓶颈识别、性能调优指导

性能测试流程简单介绍

1.分析性能需求：测试场景、性能指标确定，需求确认后需要公示项目组
2.指定性能测试计划：测试时间、测试环境、测试工具
3.编写测试用例
4.搭建测试环境，准备测试数据
5.编写性能测试脚本
6.性能脚本调优
7.设计测试场景、运行测试脚本、监控
8.分析测试结果，收集相关日志给开发
9.回归性能测试
10.编写测试报告、测试数据清理

需求分析

性能测试需求

1.客户提供需求
2.运维提供需求
3.开发提供需求

性能指标预期

1.时间指标：响应耗时，比如TOP99% 5s
2.容量指标：并发量、在线用户数最终落库的数据量
3.资源利用率指标：cpu idle 30% 、memory无剧烈抖动或者飙升
4.事务通过率：100%
5.错误率
6.TPS、QPS
7.压测过程中各接口功能是否正常

并发用户数怎么确定

1.线上数据收集，PV（页面浏览量或点击量）、UV（访客数量/天）
UV80%/（43600）
2.根据需求确定：使用高峰时间段、注册用户数、单次响应时间

性能模型

• 业务模型：用户行为流程、测试操作匹配业务模型、流程拆分、相同的流程对于不同的系统实现来说压测的指标会有不同
• 监控模型：

测试计划-性能方案

• 测试环境：线上、线下【系统拓扑图】
• 测试数据、测试模型：基于业务模型，设计用户数据、订单数据等
• 性能指标：性能需求指标
• 压力策略：递增策略，一定的并发数、预计TPS值、持续一段时间15分钟，递增加压
• 准入准出：根据性能标准，系统做适配，满足准入准出条件
• 进度风险

性能测试在什么时间执行

功能稳定后，进行基准测试
负载测试，一般放在三更半夜

性能测试环境

线下性能测试环境与线上环境：线下环境搭建最好与线上的机器配置类似或者同比缩放，机器的配比关系与线上尽量保持一致或类似，整体的拓扑结构与线上基本保持一致。
性能测试环境与业务测试环境：性能测试环境对于测试环境要求很高，可以分开。线上：压测流量不要影响到正式的流量，比如：可以单独几台机器进行压测。

测试数据准备和构造

1. 接口请求参数：自己构造/日志获取/上下关联
2. 数据表数据填充：jmeter构造、mysql构造、生产数据备份
3. 多接口，结合业务场景设计请求比例（PV）

对于多系统、多场景的造数据来说，可以进行单系统压测、再多系统压测。

如何防止数据污染

数据隔离、测试数据落入影子库、挡板、mock

场景设计

设计测试场景

• 用户行为拆分【电商为例】：用户首页浏览、进入商品详情页、加购物车、下单，根据线上监控数据，确认核心行为场景，场景的接口确认，制定请求比例
• 抽取主要核心接口：抽取行为比例，作为接口设计比例
• 如果是新产品：竞品数据参考、找到核心场景、抓包确定核心接口
  28原则，是没有一切有效数据的基础上的原则，根据实际的系统分析流量值才可取，比如：凌晨1点到早上5点半可能基本上用户量是没有的

脚本设计

jmeter原理

模拟用户发送请求到服务器，接收服务器的响应数据，设置相关参数、设计业务场景，统计应用程序或服务器的性能情况。分析衡量web应用程序和各种服务的性能和负载功能行为

jmeter常用元件

测试计划
线程组
取样器：http取样器
配置元件：CSV文件配置(参数化)、header管理、cookie管理、http default manager（全局请求信息）、counter计数器、user defined Variable
前置处理器：JSR233前置处理器（脚本语言处理，输入变量，供取样器使用）
后置处理器：JSON Extractor（根据jsonpath取字段放入变量） 、JSR233后置处理器（对取出的变量进行脚本语言处理）
定时器
监听器：查看结果树、聚合报告
断言：JSON断言（根据状态码断言）
逻辑控制器：事务控制器（在该控制器下放入相同事务的请求，定义事务）、if条件（特定的场景下，借助if控制器，判断是否执行该请求）、loop循环（根据用户行为配比，借助loop循环控制器设置循环次数，做不同的比例分配）

jmeter测试元件执行顺序

配置元件、前置处理器、计时器、取样器、后置处理器、断言、监听器

如何减少jmeter的资源需求

1.使用命令执行脚本
2.压测期间不适用查看结果树等监听器，仅在脚本编辑时使用
3.不要使用功能模式
4.用循环代替大量相似的采样器。

压测工具准备

1. jmeter
2. 脚本编写
3. 启压：执行hb.jmx压测脚本，并将结果输出到hb.jtl中
   在windows下执行

/jmeter -n -t hb.jmx -l hb.jtl

在Linux下执行

../bin/jmeter.sh -n -t hb.jmx -l hb.jtl

性能测试脚本调优

设置检查点、参数化、做关联、设置集合点、添加事务、添加断言、调整思考时间、删除冗余脚本

实现200用户的并发

在对应请求的脚本后设置集合点

think_time的作用

模拟真实生产用户操作，考察对服务器造成的影响
降低当时运行压力，缓解对应用服务器造成的压力

性能监控

客户端监控+服务端监控【系统架构、系统监控、中间件、缓存、队列、负载均衡、熔断限流、链路监控等】

性能场景执行

基准场景：新系统上线、重构、性能调优专项。
容量场景
稳定性场景

结果分析

响应时间、吞吐量、CPU、内存、io、disk

如何分析性能测试结果

1.查看事务通过率；
2.分析其他性能指标：响应时间、CPU、mem、i/o等是否满足需求
3.测试结果是否可信，不可信，分析异常，重新测试；可信，分析性能指标，并找相关人员进行优化

响应时间不达标，分析过程

事务消耗时间主要是网络传输+服务器处理
1.网络方向，首先看带宽是否存在瓶颈，如果是，考虑是否需要增加带宽，或者对数据进行压缩传输；其次需要考虑网络是否稳定。
2.服务器方向：分别查看应用服务器与数据库CPU、mem使用情况，将存在异常指标的服务器日志发给相关人员定位分析

内存泄露，JVM调优

关注内存的Heap数据，分析哪个对象消耗内存异常，并给开发进行定位。

程序在单用户场景下运行成功，多用户运行则失败，提示连不上服务器

程序可能是单线程处理机制。

如何识别系统瓶颈

从TPS指标分析，随着用户数的增长，TPS是否也会增长，如果停止增长或者出现减少的情况可能是出现瓶颈了。（单位时间内处理事务的数量）

如何判断系统性能是变好了还是变坏了

1.与基准测试对比性能指标
2.但实际上有些系统并不存在基准指标，可以将每次测试的指标情况记录下来，根据实际情况对比分析。

性能结果/报告

场景结果整理、监控结果整理、性能整体分析、性能结论、优化建议、运维建议
多次性能测试调优，得出最终结果

压测模型（简单）

压力工具–>Nginx【负载均衡】–>应用服务器1、2…–>Redis、DB

性能拐点

并发数、资源利用率、吞吐量（TPS、QPS）、响应时间
随着并发数增加，到达第一个拐点，资源利用率与吞吐量增加到平稳状态–>容量规划的最优值