Jmeter 中心原理
根据协议，模仿真实用户场景，并经过多线程模仿用户建议恳求。
- 根据协议：功能测验的对象是网络分布式架构的软件，而网络分布式架构的中心是网络协议
- 多线程：人的大脑是单线程的，电脑的 cpu 是多线程的。功能测验便是使用多 线程的技术模仿多用户去负载
- 模仿真实场景。用户的访问时刻，访问频率都不是固定的
功能测验理论
功能测验的
- 根本目标：测验体系功能是否合格；经过一定的技术手法，模仿用户的并发恳求，去测验体系最大处理才能与安稳运转的才能，找到功能瓶颈，提高体系整体处理才能
- 根本办法：基准、负载、压力……
中心原理
根据协议，经过多线程的办法模仿用户并发，在不同场景下施压服务器
- 根据协议：包含http，https，tcp，udp，socket，websocket，根据协议建议恳求
- 多线程：经过多线程的办法，模仿并发用户，施压服务器
- 涉及场景：jmeter 办法，元件；规划用户使用体系的相关，思考时刻，集合点，对成果进行断言
应用领域
- 才能验证：体系能否在固定条件下具有所声明的才能
乙方向甲方供给的项目中，声明晰体系可以支撑5000用户同时登录，且呼应时刻不超越3s;乙方需求经过功能测验得到测验成果，给予甲方验收陈述
- 瓶颈发现：发现瓶颈与缺点，无可参照的功能目标与目标
经过一系列的功能测验手法，发现功能瓶颈与缺点
- 功能调优：对体系功能的调优
针对发现的功能瓶颈做调优
- TPS 瓶颈
- 服务资源瓶颈
- 呼应时刻瓶颈
- SQL 瓶颈
- 容量规划：体系能否支撑未来一段时刻内的用户添加
当前用户可能只支撑5000用户并发;
预计未来用户并发量能到达 50000 or 500000;
针对未来可能存在的事务量迸发，以预计的用户并发量为基数，做对应的功能测验，提前调整硬件设备
测验思路
- 要测什么？
前端：web、APP；从用户视点考虑，更多重视页面加载时刻，与呼应时刻
服务端：
- 工具层面：重视错误率与吞吐量
- 服务器层面：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%，继续运转一段时刻
- 破坏性测验：在最大压力的基础上，依然不断添加压力，意图是让体系溃散报错
失效恢复测验：体系异常之后，能否及时地恢复
容量测验：考察体系在未来时刻段内，能支撑的用户数；测验大容量下，体系需求的硬件设备
