08-01 Jmeter 核心原理与性能测试理论

Jmeter 核心原理

基于协议，模拟真实用户场景，并通过多线程模拟用户发起请求。

1. 基于协议：性能测试的对象是网络分布式架构的软件，而网络分布式架构的核心是网络协议
2. 多线程：人的大脑是单线程的，电脑的 cpu 是多线程的。性能测试就是利用多 线程的技术模拟多用户去负载
3. 模拟真实场景。用户的访问时间，访问频率都不是固定的

性能测试理论

性能测试的

• 基本目标：测试系统性能是否达标；通过一定的技术手段，模拟用户的并发请求，去测试系统最大处理能力与稳定运行的能力，找到性能瓶颈，提升系统整体处理能力
• 基本方法：基准、负载、压力……

核心原理

基于协议，通过多线程的方式模拟用户并发，在不同场景下施压服务器

• 基于协议：包括http，https，tcp，udp，socket，websocket，基于协议发起请求
• 多线程：通过多线程的方式，模拟并发用户，施压服务器
• 涉及场景：jmeter 方法，元件；设计用户使用系统的关联，思考时间，集合点，对结果进行断言

应用领域

• 能力验证：系统能否在固定条件下具有所声明的能力

  乙方向甲方提供的项目中，声明了系统可以支持5000用户同时登录，且响应时间不超过3s;乙方需要通过性能测试得到测试结果，给予甲方验收报告

• 瓶颈发现：发现瓶颈与缺陷，无可参照的性能指标与目标

  通过一系列的性能测试手段，发现性能瓶颈与缺陷

• 性能调优：对系统性能的调优

  针对发现的性能瓶颈做调优

• TPS 瓶颈
• 服务资源瓶颈
• 响应时间瓶颈
• SQL 瓶颈
• 容量规划：系统能否支持未来一段时间内的用户增长

当前用户可能只支持5000用户并发;
预计未来用户并发量能达到 50000 or 500000;
针对未来可能存在的业务量爆发，以预计的用户并发量为基数，做对应的性能测试，提前调整硬件设施

测试思路

• 要测什么？

前端：web、APP；从用户角度考虑，更多关注页面加载时间，与响应时间

服务端：

1. 工具层面：关注错误率与吞吐量
2. 服务器层面：CPU，内存，IO，JVM

数据库：包括慢SQL，死锁……

• 怎么测？

需求--计划--方案--测试环境搭建--设计用例--数据准备--设计场景--脚本开发--数据监控--结果分析--性能调优--提交报告

• 测试结果通过的标准：

按照需求：测试结果符合预期

无标准需求的：例如测试一个页面的最大并发

性能指标

• 前端性能指标

响应时间：用户视角最优先关注的指标

• 258原则：

  • 2s以内，很满意
  • 5s，一般
  • 8s，无法接受

• 前端相应时间：

  • 前端资源加载渲染的时间
  • 前后端交互的时间
  • 前端将后端查询的数据，在页面呈现出来

• 网络连接时间：

  • connect time-连接时间：请求发出到服务端接收到，中间的网络时间
  • latency-延迟：网络连接时间+服务处理返回的时间
• 服务段处理时间=latency - connect time

错误率

点击率（HPS）：用户点击按钮，触发请求

TPS：

• 单接口业务：单位时间完成的请求数
• 多接口业务：单位时间完成的事务数

RPS：直接从服务端角度衡量压力值

• 单位时间发起的请求数

TPS 衡量了服务端/系统的性能；RPS 衡量了压力

• 服务端性能指标

CPU

内存

磁盘IO

JVM

中间件：Tomcat、redis、Nginx

测试视角

用户视角

• 响应时间
• 系统稳定

运维视角

• 硬件设施是否需要更换

• 资源利用率是否达标

  • 利用率超标
  • 利用率过低
• 系统容量

开发视角

• 代码是否需要优化
• SQL 优化
• 系统架构优化

性能测试工程师的视角

测试类型

基准测试：每一次版本迭代都需要做基准测试，目的是对比上一次的测试结果，给出调优的依据

负载测试：持续不断地增加压力；需要保证压力的持续性；找到系统的瓶颈点

• 并发用户模型：持续不断地增加并发用户
• RPS模型：持续不断地增加请求数

压力测试：当资源处于一个饱和状态，持续运行服务，考察系统的稳定性；或者负载处于一个高峰

• 稳定性测试：最大压力的80%，持续运行一段时间
• 破坏性测试：在最大压力的基础上，依然不断增加压力，目的是让系统崩溃报错

失效恢复测试：系统异常之后，能否及时地恢复

容量测试：考察系统在未来时间段内，能支撑的用户数；测试大容量下，系统需要的硬件设施