性能与压力测试

一、性能监控

1.1 jvm内存模型—堆

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

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

清楚了堆的细分后，下面介绍新对象申请堆空间的处理流程：


GC具体流程如下:

1. 首先，新对象产生时，JVM需要为该对象进行内存空间的申请
2. 判断Eden区是否有内存空间放下该新对象，如果有，则直接将其保存至Eden区
3. 如果Eden区空间不足，则会自动执行一个YGC，即Minor GC操作，将Eden区的无用内存空间进行清理
4. 清理Eden区之后继续判断Eden区内存空间情况，如果充足，则将新对象直接保存在Eden区
5. 如果执行了Minor GC之后发现Eden区的内存依然不足，则说明该新对象是一个大对象，此时判断老年区空间是否充足，如果充足，则将其保存至老年区
6. 如果老年区空间不足，则进行一次Full GC清理内存
7. 进行Full GC后，继续判断老年区是否有充足空间，如果充足，则将新对象保存至老年区
8. 如果执行了Full GC后发现老年区的内存依然不足，则会报错OutOfMemoryError
9. 每进行一次YGC（Minor GC）后，判断幸存者区（Survivor）是否有足够的空间，如果有，则那些未被清理的对象将迁移至幸存者区
10. 如果幸存者区没有足够的空间了，则那些未被清理的对象会保存至老年区
11. 每次Minor GC后，若处于幸存者区的幸存对象未超过存活阈值，则他们会在S0和S1两块区域中来回迁移，以尽可能留出大块的空闲区以接收每次Minor GC后的幸存对象
12. 每次Minor GC后，若幸存的对象超过了存活阈值，则会将其迁移至老年区

需要特别关注的几点：

• 对象优先在Eden区分配，若空间不够，就发生一次Minior GC。
• 大对象直接进入老年代，最典型的大对象就是那种很长的字符串以及数组
• 长期存活的对象将进入老年代，虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1，当它的年龄增加到一定程度（默认为15岁），就将会被晋升到老年代中。

1.2 jconsole 与 jvisualvm

Jdk 的两个小工具 jconsole、jvisualvm（升级版的 jconsole）;通过命令行启动，可监控本地和远程应用。远程应用需要配置。
（1）jvisualvm 能干什么
监控内存泄露，跟踪垃圾回收，执行时内存、cpu 分析，线程分析…

运行：正在运行的
休眠：sleep
等待：wait
驻留：线程池里面的空闲线程
监视：阻塞的线程，正在等待锁
(2)安装插件方便查看 gc

• Cmd 启动 jvisualvm
• 工具->插件
  
  
• 如果 503 错误解决：
  打开网址 https://visualvm.github.io/pluginscenters.html，cmd 查看自己的 jdk 版本，找到对应的，复制下面查询出来的链接。并重新设置上即可
  

1.3 监控指标

（1）中间件指标

• 当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线程数最小值设置 50 和最大值设置 200 比较合适。
• 当前运行的 JDBC 连接数不能超过设定的最大值。一般情况下系统性能较好的情况下，JDBC 最小值设置 50 和最大值设置 200 比较合适。
• ＧＣ频率不能频繁，特别是 FULL GC 更不能频繁，一般情况下系统性能较好的情况下，JVM 最小堆大小和最大堆大小分别设置 1024M 比较合适。

（2）数据库指标

• SQL 耗时越小越好，一般情况下微秒级别。
• 命中率越高越好，一般情况下不能低于 95%。
• 锁等待次数越低越好，等待时间越短越好。

1.4 JVM分析与调优

jvm 调优，调的是稳定，并不能带给你性能的大幅提升。服务稳定的重要性就不用多说了，保证服务的稳定，gc 永远会是 Java 程序员需要考虑的不稳定因素之一。复杂和高并发下的服务，必须保证每次 gc 不会出现性能下降，各种性能指标不会出现波动，gc 回收规律而且干净，找到合适的 jvm 设置。Full gc 最会影响性能，根据代码问题，避免 full gc 频率。可以适当调大年轻代容量，让大对象可以在年轻代触发 yong gc，调整大对象在年轻代的回收频次，尽可能保证大对象在年轻代回收，减小老年代缩短回收时间；

具体调优项，参见官网：https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html#BGBCIEFC

二、压力测试

压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。使用压力测试，我们有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是: 内存泄漏，并发与同步。
有效的压力测试系统将应用以下这些关键条件:重复，并发，量级，随机变化。

2.1 性能指标

1. 响应时间（Response Time: RT）：响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。
2. HPS（Hits Per Second） ：每秒点击次数，单位是次/秒。
3. TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。
4. QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。 注意：对于互联网业务中，如果某些业务有且仅有一个请求连接，那么 TPS=QPS=HPS，一般情况下用 TPS 来衡量整个业务流程，用 QPS 来衡量接口查询次数，用 HPS 来表示对服务器单击请求。无论 TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下：
   金融行业：1000TPS~50000TPS，不包括互联网化的活动
   保险行业：100TPS~100000TPS，不包括互联网化的活动
   制造行业：10TPS~5000TPS
   互联网电子商务：10000TPS~1000000TPS
   互联网中型网站：1000TPS~50000TPS
   互联网小型网站：500TPS~10000TPS
5. 最大响应时间（Max Response Time）： 指用户发出请求或者指令到系统做出反应（响应）的最大时间。
6. 最少响应时间（Mininum ResponseTime） ：指用户发出请求或者指令到系统做出反应（响应）的最少时间。
7. 90%响应时间（90% Response Time）： 是指所有用户的响应时间进行排序，第 90%的响应时间

从外部看，性能测试主要关注如下三个指标：

• 吞吐量：每秒钟系统能够处理的请求数、任务数。
• 响应时间：服务处理一个请求或一个任务的耗时。
• 错误率：一批请求中结果出错的请求所占比例。

2.2 压测工具 - JMeter

1. 安装，从链接https://jmeter.apache.org/download_jmeter.cgi 中下载对应的压缩包，解压运行 jmeter.bat即可。
2. JMeter 压测示例
   （1）添加线程组
   
   
   线程组参数详解：

• 线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。
• Ramp-Up Period(in seconds)准备时长：设置的虚拟用户数需要多长时间全部启动。如果线程数为 10，准备时长为 2，那么需要 2 秒钟启动 10 个线程，也就是每秒钟启动 5 个线程。
• 循环次数：每个线程发送请求的次数。如果线程数为 10，循环次数为 100，那么每个线程发送 100 次请求。总请求数为 10*100=1000 。如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本
• Delay Thread creation until needed：直到需要时延迟线程的创建。
• 调度器：设置线程组启动的开始时间和结束时间(配置调度器时，需要勾选循环次数为永远)
• 持续时间（秒）：测试持续时间，会覆盖结束时间
• 启动延迟（秒）：测试延迟启动时间，会覆盖启动时间
• 启动时间：测试启动时间，启动延迟会覆盖它。当启动时间已过，手动只需测试时当前时间也会覆盖它。
• 结束时间：测试结束时间，持续时间会覆盖它。

（2）添加 HTTP 请求


（3）添加监听器

（4）启动压测 & 查看分析结果

压测具体案例：

影响性能的原因如下：
中间件越多，性能损失越大，大多都损失在网络交互了；
业务：Db（MySQL 优化）、模板的渲染速度（缓存）、静态资源

（5）结果分析

• 有错误率同开发确认，确定是否允许错误的发生或者错误率允许在多大的范围内；
• Throughput 吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；
• 压测结束，登陆相应的 web 服务器查看 CPU 等性能指标，进行数据的分析;
• 最大的 tps，不断的增加并发数，加到 tps 达到一定值开始出现下降，那么那个值就是最大的 tps。
• 最大的并发数：最大的并发数和最大的 tps 是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。
• 压测过程出现性能瓶颈，若压力机任务管理器查看到的 cpu、网络和 cpu 都正常，未达到 90%以上，则可以说明服务器有问题，压力机没有问题。
• 影响性能考虑点：
  首先考虑自己的应用属于 CPU 密集型还是 IO 密集型，数据库、应用程序、中间件（tomact、Nginx）、网络和操作系统等方面都会影响性能

3. JMeter Address Already in use 错误解决

windows 本身提供的端口访问机制的问题。
Windows 提供给 TCP/IP 链接的端口为 1024-5000，并且要四分钟来循环回收他们。就导致我们在短时间内跑大量的请求时将端口占满了。

解决办法:
(1) cmd 中，用 regedit 命令打开注册表
(2) 在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 下，

• 右击 parameters，添加一个新的 DWORD，名字为 MaxUserPort
• 然后双击 MaxUserPort，输入数值数据为 65534，基数选择十进制（如果是分布式运行的话，控制机器和负载机器都需要这样操作哦）
  (3) 修改配置完毕之后记得重启机器才会生效
  https://support.microsoft.com/zh-cn/help/196271/when-you-try-to-connect-from-tcp-ports-grea
  ter-than-5000-you-receive-t
  TCPTimedWaitDelay：30