gulimall-性能监控-压力测试

性能监控与压力测试

  • 前言
  • 一、性能监控
    • 1.1 jvm 内存模型
    • 1.2 jvisualvm 作用
    • 1.3 监控指标
  • 二、压力测试
    • 2.1 概念
    • 2.2 性能指标
    • 2.3 JMeter 压测工具

前言

本文继续记录B站谷粒商城项目视频 P141-150 的内容,做到知识点的梳理和总结的作用。

一、性能监控

1.1 jvm 内存模型

1.JVM 主要由三个子系统构成:类加载器子系统、运行时数据区和字节码执行引擎。
gulimall-性能监控-压力测试_第1张图片
Java 虚拟机在执行 java 程序的过程中会把它管理的内存划分为若干个不同的数据区域。这些区域有各自的用途,以及创建和销毁的时间,有的区域随着虚拟机进程的启动而一直存在,有些区域则依赖于用户线程的启动和结束而创建和销毁。根据《Java虚拟机规范》的规定,Java虚拟机所管理的的内存将会包括以下几个运行时数据区:

1.程序计数器:Program Counter Register

  • 记录的是当前线程正在执行的虚拟机字节码指令的地址。
  • 此内存区域是唯一一个在JAVA虚拟机规范中没有规定任何OutOfMemoryError的区域。

2.虚拟机:VM Stack

  • 描述的是 JAVA 方法执行的内存模型,每个方法在执行的时候都会创建一个栈帧,用于存储局部变量表,操作数栈,动态链接,方法接口等信息。

  • 局部变量表存储了编译期可知的各种基本数据类型、对象引用。

  • 线程请求的栈深度不够会报 StackOverflowError 异常。

  • 栈动态扩展的容量不够会报 OutOfMemoryError 异常。

  • 虚拟机栈是线程隔离的,即每个线程都有自己独立的虚拟机栈。

  • 在Java中,每个线程都会有一个单独的栈区,每个栈中的元素都是私有的,不会被其他的栈所访问。栈中的数据大小和生存期都是确定的,存取速度比较快。

  • 在Java中,所有的基本数据类型(byte、short、int、long、float、double、boolean、char)和引用变量(对象引用)都是在栈中的。一般情况下,线程退出或者方法退出时,栈中的数据会被自动清除。

3.本地方法:Native Stack

  • 本地方法栈类似于虚拟机栈,只不过本地方法栈使用的是本地方法。

4.堆:Heap

  • 堆中主要存储的是实际创建的对象,也就是会存储通过 new 关键字创建的对象,堆中的对象能够被多个线程共享。堆中的数据不需要事先明确生存期,可以动态的分配内存,不再使用的数据和对象由 JVM 中的 GC 机制自动回收。对 JVM 的性能调优一般就是对堆内存的调优。

  • 堆一般会被分成年轻代和老年代。而年轻代又会被进一步分为 1 个 Eden 区和 2 个 Survivor 区。在内存分配上,如果保持默认配置的话,年轻代和老年代的内存大小比例为 1 : 2,年轻代中的 1 个 Eden 区和 2 个 Survivor 区的内存大小比例为:8 : 1 : 1。

5.方法区:Method Area

  • 方法区的另一个名字叫作元空间,这个区域是 JDK1.8 中划分出来的。主要包含:运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应的 Class 实例的引用等信息。方法区中的信息能够被多个线程共享。
    gulimall-性能监控-压力测试_第2张图片

gulimall-性能监控-压力测试_第3张图片
2.堆

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

新生代

  • Eden 空间
  • From Survivor 空间
  • To Survivor 空间

老年代

  • 永久代/元空间
  • Java8 以前永久代,受 jvm 管理,java8 以后元空间,直接使用物理内存。因此默认情况下,元空间的大小仅受本地内存限制。

3.垃圾回收

gulimall-性能监控-压力测试_第4张图片

从 Java8 开始,HotSpot 已经完全将永久代移除,取而代之的是一个新的区域—元空间。

gulimall-性能监控-压力测试_第5张图片

gulimall-性能监控-压力测试_第6张图片

1.2 jvisualvm 作用

监控内存泄露,跟踪垃圾回收,执行时内存、cpu 分析,线程分析等。

gulimall-性能监控-压力测试_第7张图片

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

循环监测Nginx

gulimall-性能监控-压力测试_第8张图片
虚拟机 nginx 占用的 cpu 飙升

gulimall-性能监控-压力测试_第9张图片

循环监测网关

gulimall-性能监控-压力测试_第10张图片

Jvisualvm 工具监控网关微服务

gulimall-性能监控-压力测试_第11张图片

1.3 监控指标

压测内容 压测线程数 吞吐量/s 90%响应时间 99%响应时间
Nginx 50 2230 32 71
Gateway 50 7770 7 24
简单服务 50 7787 13 31
首页一级菜单渲染 50 123(db + thymeleaf) 558 852
首页渲染(开缓存) 50 254 5045 5347
首页渲染(开缓存、优化数据库、关日志) 50 650 4266 5140
三级分类数据获取 50 2 (db) 4930 5422
三级分类(优化业务) 50 80 787 1118
首页全量数据获取 50 9(静态资源) 6662 8781
Nginx+简单服务 50 2078 34 142
Nginx+Gateway 50 850 56 112
全链路 50 407 158 284

中间件越多,性能损失越大,大多都损失在网络交互了:

  • 业务
  • DB(MySQL 优化)
  • 模板的渲染速度(缓存)
  • 静态资源

二、压力测试

2.1 概念

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

2.2 性能指标

  • 响应时间(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
    互联网电子商务:10000TPS~1000000TPS
    互联网中型网站:1000TPS~50000TPS
    互联网小型网站:500TPS~10000TPS
  • 最大响应时间(Max Response Time) 指用户发出请求或者指令到系统做出反应(响应)
    的最大时间。
  • 最少响应时间(Mininum ResponseTime) 指用户发出请求或者指令到系统做出反应(响
    应)的最少时间。
  • 90%响应时间(90% Response Time) 是指所有用户的响应时间进行排序,第 90%的响应时间。
  • 从外部看,性能测试主要关注如下三个指标
    吞吐量:每秒钟系统能够处理的请求数、任务数。
    响应时间:服务处理一个请求或一个任务的耗时。
    错误率:一批请求中结果出错的请求所占比例。

2.3 JMeter 压测工具

JMeter 下载地址: https://jmeter.apache.org/download_jmeter.cgi

gulimall-性能监控-压力测试_第12张图片

下载对应的压缩包,解压运行 jmeter.bat 即可

3.1 JMeter 压测示例

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

gulimall-性能监控-压力测试_第15张图片

gulimall-性能监控-压力测试_第16张图片

  1. 添加监听器

gulimall-性能监控-压力测试_第17张图片

  1. 启动压测&查看分析结果

gulimall-性能监控-压力测试_第18张图片

结果分析:

  • 有错误率同开发确认,确定是否允许错误的发生或者错误率允许在多大的范围内。
  • Throughput 吞吐量每秒请求的数大于并发数,则可以慢慢的往上面增加;若在压测的机器性能很好的情况下,出现吞吐量小于并发数,说明并发数不能再增加了,可以慢慢的往下减,找到最佳的并发数。
  • 压测结束,登陆相应的 web 服务器查看 CPU 等性能指标,进行数据的分析。
  • 最大的 tps,不断的增加并发数,加到 tps 达到一定值开始出现下降,那么那个值就是最大的 tps。
  • 最大的并发数:最大的并发数和最大的 tps 是不同的概率,一般不断增加并发数,达到一个值后,服务器出现请求超时,则可认为该值为最大的并发数。
  • 压测过程出现性能瓶颈,若压力机任务管理器查看到的 cpu、网络和 cpu 都正常,未达到 90%以上,则可以说明服务器有问题,压力机没有问题。
  • 影响性能考虑点包括:数据库、应用程序、中间件(tomact、Nginx)、网络和操作系统等方面。
  • 首先考虑自己的应用属于 CPU 密集型还是 IO 密集型。
  1. JMeter Address Already in use 错误解决
  • windows 本身提供的端口访问机制的问题。Windows 提供给 TCP/IP 链接的端口为 1024-5000,并且要四分钟来循环回收他们。就导致我们在短时间内跑大量的请求时将端口占满了。
    1.cmd 中,用 regedit 命令打开注册表
    2.在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 下,
    1.右击 parameters,添加一个新的 DWORD,名字为 MaxUserPort
    2.然后双击 MaxUserPort,输入数值数据为 65534,基数选择十进制(如果是分布式运行的话,控制机器和负载机器都需要这样操作哦)
    3.修改配置完毕之后记得重启机器才会生效

参开链接: https://support.microsoft.com/zh-cn/help/196271/when-you-try-to-connect-from-tcp-ports-greater-than-5000-you-receive-t

你可能感兴趣的:(gulimall,谷粒商城,JVM,虚拟机,SpringBoot,框架,java,jvm,jmeter,jvisualvm)