压力测试 & 性能监控

性能监控

jvm 内存模型

程序计数器Program Counter Register：
- 记录的是正在执行的虛拟机字节码指令的地址，
- 此内存区域是唯一个在 JAVA虚拟机规范中没有规定任何OutOfMemoryError的区域
虚拟机： VMStack
- 描述的是 JAVA方法执行的内存模型，每个方法在执行的时候都会创建一一个栈帧，用于存储局部变量表，操作数栈，动态链接，方法接口等信息
- 局部变量表存储了编译期可知的各种基本数据类型、对象引用
- 线程请求的栈深度不够会报StackOverflowError异常
- 栈动态扩展的容量不够会报OutOfMemoryError异常
- 虚拟机栈是线程隔离的，即每个线程都有自己独立的虚拟机栈
本地方法： Native Stack
- 本地方法栈类似于虚拟机栈，只不过本地方法栈使用的是本地方法
堆：Heap（优化的重点）
- 几乎所有的对象实例都在堆上分配内存优化重点

堆（deep)

所有的对象实例以及数组都要在堆上分配。堆是垃圾收集器管理的主要区域，也被称为“GC堆”；也是我们优化最多考虑的地方。
堆可以细分为：

新生代
- Eden空间（伊甸园区）
- From Survivor空间（幸存者区）
- To Survivor空间
老年代
永久代/元空间
- Java8以前永久代受jvm管理，java8 以后元空间，直接使用物理内存。因此，默认情况下，元空间的大小仅受本地内存限制。

垃圾回收

从Java8开始，HotSpot已经完全将永久代（Permanent Generation）移除，取而代之的是一个新的区域一元空间（MetaSpace）

对象创建过程：

new Xxx() -> 判断eden（伊甸园区）是否放得下，如果放不下进行一次YGC（小gc），会将旧对象放入survive区中。

如果YGC之后对象还放不下，将旧对象放入老年区中。

如果老年区还放不下，进行一次FGC（大gc）。FGC非常慢，一次FGC相当于10次YGC。

进行FGC之后，老年区还放不下就报错 oom out of memory

将旧对象放入survive的细节。YGC 把没用的对象移除，把旧对象（就是eden里面的有用的对象）移入survive（如果可以的话，不可以就直接放入老年区）。而servive分成survive0和survive1。survive0 和 survive1 里面的对象相互移动，目的是为了腾出更大的空间，来存放一个大对象。

保存在幸存者区（survive）里面的对象经过多次YGC 如果还存活着就会将这些年龄大的对象移入老年区。

在性能优化期间，我们要时刻关注 eden 和老年区的内存动态变化，并进行相应的调优才行。

我们说的垃圾回收都是指的是heap 堆区，说道垃圾回收，回收的就是堆，所有新对象的创立、存放都是在deap区。

jconsole 与 jvisualvm

jvisualvm 能干什么

监控内存泄露，跟踪垃圾回收，执行时内存、 Cpu 分析，线程分析…

运行口休眠口等待驻留监视
运行：正在运行的
休眠： sleep
等待： wait
驻留：线程池里面的空闲线程
监视：阻塞的线程，正在等待锁

启动 jconsole 、jvisualvm。

可以发现这两个都是安装jdk 的时候里面的可执行文件，直接在控制台执行命令即可

安装插件方便查看垃圾回收过程

默认是无法监控到eden 区老年区 survive 区的内存情况，需要安装插件才可以

插件中心

监控指标

中间件指标

数据库指标

JVM分析&调优

几个常用工具

命令实例

调优项

我们项目的调用流程流程：用户-> nginx -> gateway -> 微服务。所以请求到底微服务经历了两个中间件（nginx、gateway）。我们先测试中间件的影响大不大

中间件越多，性能损失越大，大多都损失在网络交互了
业务：
- Db （MySQL 优化）
- 模板的渲染速度（CPU）
- 静态资源

查看docker 资源使用情况 [vagrant@haitao-gmall-advance ~]$ docker stats

[vagrant@haitao-gmall-advance ~]$ top

[vagrant@haitao-gmall-advance ~]$ sudo swapoff -a

-Xmx1024m -Xms1024 -Xmn512m 最大内存、最小内存、伊甸园的内存

压力测试

压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。压测都是为了系统在线上的处理能力和稳定性维持在一个标准范围内，做到心中有数。
使用压力测试，我们有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是：内存泄漏，并发与同步。
有效的压力测试系统将应用以下这些关键条件：重复，并发，量级，随机变化。

性能指标

响应时间（Response Time： RT）
- 响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。
HPS （Hits Per Second）：每秒点击次数，单位是次秒。
TPS （Transaction per Second）；系统每秒处理交易数，单位是笔/秒。
QPS （Query per Second）：系统每秒处理查询次数，单位是次/秒。
- 对于互联网业务中，如果某些业务有且仅有一一个请求连接，那么TPS=QPS=HPS，一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器单击请求。
无论TPS、QPS、HPS，此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下：
- 金融行业： 1000TPS~50000TPS，不包括互联网化的活动
- 保险行业： 100TPS~100000TPS，不包括互联网化的活动
- 制造行业： 10TPS~5000TPS
- 互联网电子商务： 10000PS~100000TPS
- 互联网中型网站： 1000TPS~50000TPS
- 互联网小型网站： 500TPS~10000TPS
最大响应时间（Max Response Time）指用户发出请求或者指令到系统做出反应（响应）的最大时间。
最少响应时间（Mininum ResponseTime）指用户发出请求或者指令到系统做出反应（响应）的最少时间。
90%响应时间（90% Response Time）是指所有用户的响应时间进行排序，第90%的响应时间。
从外部看，性能测试主要关注如下三个指标
- 吞吐量：每秒钟系统能够处理的请求数、任务数。
- 响应时间：服务处理一一个请求或一个任务的耗时。
- 错误率：一批请求中结果出错的请求所占比例。
- 这三个指标可以通过JMter的汇总报告、聚合报告查看、如果想看响应体内容可以通过察看结果树