课程安排，每周二周四，共3周-6节课
预计4个阶段，到微服务。第二阶段是调优
需要做虚拟机搭建
一、性能测试和功能测试的区别
1、功能测试：是一个非黑即白的过程。是和非。测不到更深层的东西，有些bug无法通过肉眼去发现和校验。需要使用工具（postman请求、抓包、代理）
测一辆汽车：是否存在这个功能，能不能正常使用。
2、性能测试：看一个东西好不好用。最重要的是：找到这个程序的极限值。找极限的目的：保证系统上线后能正常运行，不会遇到突发情况导致崩溃，而造成经济损失。只要找到了极限值，就可以做预警机制。
测一辆汽车：噪音大不大，百公里加速多少。
二、可能影响性能的因素：
开发的代码属于工业化的代码
cpu执行代码，内存存储数据。线程多，CPU处理起来慢
CPU：核心执行器。计算机的大脑
3、请求的处理过程
执行的代码，通过线程，运行到CPU，由CPU执行所有的脚本代码。（线程就相当于卡车的概念）
code是代码
请求的线程多的时候
4、一个http请求的过程
1个线程，占用内存资源，会小于等于1兆
通过URL的后缀，服务器判断应该执行什么函数（在controller层），所有这个后缀的请求，都执行这个函数。
例如：queryByPage
请求的线程多的时候
CPU处理不过来（把CPU看作银行的办理窗口）
性能测试的流程
浏览器发起一个网络请求，网络请求会占用网络资源，先通过网卡，请求后端的程序，程序执行占用内存，内存创建线程，线程请求CPU，CPU做对线程的处理，把数据存储到磁盘（永久化存储）
三、性能测试的指标
1、响应时间
一个请求完成的时间：等待时间（不可控）+处理时间（可控）
一个程序的性能越好，等待时间越短。这样就会越好。而等待时间受处理时间影响，处理时间越快，等待时间可能越少。处理时间越慢，等待时间一定会越长。
当程序的某个接口处理时间、响应时间较长时，就需要优化它。
1.1）网页响应的时间，是该页面上嵌套的多个页面（模块）的资源响应时间的累计。
1.2）接口响应的时间：就是一个完整接收响应的时长。
2、并发量
相对并发：一段时间内向服务器，发出请求的并发（人的操作，会有间隔）--相对并发没啥压力
绝对并发：一个时间点，服务器收到的请求数量----绝对并发压力大
用户，关注：页面响应时间和接口响应时间。因为这个是性能的结果---好用不好用的结果
3、资源占用率
资源占用率：程序运行的角度一个用户请求过来，对服务器资源占用多少
老板，关注资源占用率，
4、吞吐量：
Jmeter只统计吞吐量，不统计QPS和TPS---面试题
1）QPS：每秒查询率（Query Per Second）,不涉及数据变化的操作
2）TPS：每秒事务处理数（Transactions Per Second），涉及数据变更的操作
表现形式：数字/s，表示程序处理能力的综合体现（每秒处理多少事务的能力），数字越大越好
3）上面是QPS和TPS是事后统计出来的
4）得用（或者模拟）和生产服务器，配置一模一样的服务器进行压测。所以压测前，需要问研发或者测试负责人，明确使用什么样的配置进行性能测试
16核是啥意思
吞吐量例子：
例子1：
银行大厅：处理请求
两个窗口接待客户，1个窗口每接待一个客户需要15分钟
一次来了10个人（两个窗口同时分别接待1个人，这就是并发）2个去办理业务，8个人等待。
15分钟后两个人办理完毕走了，此时（吞吐量）就是2
当吞吐量过低时：10分钟又来了10个人，越来越多挤满所有的空间
例子2：
银行大厅：处理请求
10个窗口接待客户，1个窗口每接待一个客户需要15分钟
上午来了两个人吞吐量最多是2，并发量是2
下午来了四个人吞吐量最多是4，并发量是4
吞吐量有一个上限，但是一旦请求数量不够，我们无法正确获得吞吐量.所以此时需要通过加并发来加压
慢慢获得一个对应的吞吐量四、正常的平台
1：45：16开始讲实际的项目部署和JMeter
jmeter不需要玩很深，会简单使用就行
性能测试的手法很简单，只要能调通接口，就能开展性能测试
四、Jmeter的基础使用
1、创建测试计划，并添加线程组
2、在线程组里写上对应的http请求
3、 添加观察结果树
4、 然后继续写HTTP请求内容就可以了
接口参数：
中文的地方需要注意，不然会报错
5、查看接口调用的结果
五、Jmeter的性能测试使用
1、设置http默认请求值
2、 为接口请求增加断言
这里使用JSON path
根据接口返回的状态码、message进行断言即可
3、性能测试的开展
1）需要做个基准测试：
用最少的并发，确定每一次用户操作需要占用的资源和性能指标
4、 添加监听器的聚合报告和汇总报告
5、 配置TPS
6、增加随时间变化的响应时间
7、随时间变化的活动线程数--最重要
8、 运行基准测试
但是基准测试不算重要，因为它不能找到性能瓶颈的根源。
9、查看执行情况
1）
2）
3）异常率--最重要指标
异常率默认小于等于0.05%，才可以通过。根据公司实际要求来。超过1%就是一定不合格
因为跑很长实际，允许有异常情况
4）吞吐量
1个吞吐量是TPS+QPS
单个线程的吞吐量如此，放大100倍、1000倍去观察
9、通过负载测试去找瓶颈
1、 
持续1分钟后，开始回收
10、关闭基准测试
清除数据
每次新执行的是线程组，不是测试计划
11、执行负载测试
12、 压测瓶颈点判断
负载测试：通过梯度压测，找到对应的瓶颈点，找到之后，我们需要去做验证。这个时候要添加一个新的线程组
310个线程，并发数是1的话，就是一个线程1秒跑一个请求，一共就是一秒310个请求。上图是在请求数为310的时候，出现瓶颈问题。
1）添加常数吞吐量定时器 --控制发请求的节奏
310是并发数量，不配置这个定时器，有可能1秒钟不是310个并发
设置吞吐量定时器 ，会限制了并发，因为我们已经知道并发数的瓶颈，所以可以限制
并发数，对应的是1个请求同时存在多少线程数。
线程和请求不一样，线程是用户，一个线程可以在一段时间发起多个请求。限制每秒发1个请求才能控制住线程是请求情况。实际可能第1秒发2个，第2秒发8个，每次都不一样。
同步定时器，310个线程，一秒可能跑出400个请求。所以不好控制。必须设置常量定时器
并发数是，N个线程一起执行的并发数就是N
每秒请求数*线程数=并发数
并发数=线程数×TPS--正确的
配置常数吞吐量定时器后：
TPS这里＝每分钟目标吞吐量÷60 =每秒钟吞吐量（吞吐的请求数量）
每秒钟发1个请求，310个并发数，就是每秒发310个请求
每秒钟发2个请求，想要每秒发310个并发数，就是应该配置155个线程数。
线程组控制的是并发用户数，吞吐量定时器是控制一个用户1分钟往服务器发多少个请求，设置1分钟发60个，就是1秒1个，我们的线程设置的310，就是1秒310个并发
意义
此时TPS=1.每秒处理1个
常量吞吐器一般设置为60就不用管了，就是一秒一个请求
如果下面每秒发310，系统就不行了，说明310在瓶颈之上
计算逻辑是：
120意味着每秒发2个
TPS=2
13、通过汇总报告，观察异常
执行
往上加线程数，1秒请求341个
做对应的压测·上调和下调线程数，找到对应的一个瓶颈范围。
进行上浮，找瓶颈
