持续学习&持续更新中…
守破离
【雷丰阳-谷粒商城 】【分布式高级篇-微服务架构篇】【13】压力压测JMeter-性能监控jvisualvm
压力测试
概述
- 压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。
- 压测都是为了将系统在线上的处理能力和稳定性维持在一个标准范围内,做到心中有数。
- 使用压力测试,我们有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是: 内存泄漏,并发与同步。
- 有效的压力测试系统将应用以下这些关键条件:重复,并发,量级,随机变化。
性能指标
-
响应时间(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%的响应时间。
从外部看,性能测试主要关注如下三个指标:
- 吞吐量:每秒钟系统能够处理的请求数、任务数。
- 响应时间:服务处理一个请求或一个任务的耗时。
- 错误率:一批请求中结果出错的请求所占比例。
JMeter
基本使用
JMeter5.2.1 安装:https://jmeter.apache.org/download_jmeter.cgi 下载对应的压缩包,解压运行 jmeter.bat 即可
jmeter语言切换
不止可以测HTTP请求
类似于扫把的图标都可以试着点一下:
添加线程组
线程组参数详解:
- 线程数:虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里 也就是设置多少个线程数。
- Ramp-Up Period(in seconds)准备时长:设置的虚拟用户数需要多长时间全部启动。如果线程数为 10,准备时长为 2,那么需要 2 秒钟启动 10 个线程,也就是每秒钟启动 5 个线程。
- 循环次数:每个线程发送请求的次数。如果线程数为 10,循环次数为 100,那么每个线程发送 100 次请求。总请求数为 10*100=1000 。如果勾选了“永远”,那么所有线程会一直发送请求,一到选择停止运行脚本。
- Delay Thread creation until needed:直到需要时延迟线程的创建。
- 调度器:设置线程组启动的开始时间和结束时间(配置调度器时,需要勾选循环次数为永远)
- 持续时间(秒):测试持续时间,会覆盖结束时间
- 启动延迟(秒):测试延迟启动时间,会覆盖启动时间
- 启动时间:测试启动时间,启动延迟会覆盖它。当启动时间已过,手动只需测试时当前时间也会覆盖它。
- 结束时间:测试结束时间,持续时间会覆盖它。
添加 HTTP 请求
添加监听器
查看结果树:
汇总报告:
聚合报告:
汇总图:
启动压测&查看分析结果
结果分析:
- 有错误率,向开发确认,确定是否允许错误的发生或者错误率允许在多大的范围内
- Throughput 吞吐量每秒请求的数大于并发数,则可以慢慢的往上面增加;若在压测的机器性能很好的情况下,出现吞吐量小于并发数,说明并发数不能再增加了,可以慢慢的往下减,找到最佳的并发数;
- 压测结束,登陆相应的 web 服务器查看 CPU 等性能指标,进行数据的分析;
- 最大的 tps,不断的增加并发数,加到 tps 达到一定值开始出现下降,那么那个值就是 最大的 tps。
- 最大的并发数:最大的并发数和最大的 tps 是不同的概率,一般不断增加并发数,达到一个值后,服务器出现请求超时,则可认为该值为最大的并发数。
- 压测过程出现性能瓶颈,若压力机任务管理器查看到的 cpu、网络都正常,未达到 90% 以上,则可以说明服务器有问题,压力机没有问题。
影响性能考虑点包括:
-
数据库、应用程序、中间件(tomact、Nginx)、网络和操作系统等方面
-
首先考虑自己的应用属于 CPU 密集型(大量计算)还是 IO 密集型(网络IO/磁盘IO)
JMeter Address Already in use 错误解决
Windows 本身提供的端口访问机制的问题。
Windows 提供给 TCP/IP 链接的端口为1024-5000,并且要四分钟来循环回收他们。就导致我们在短时间内跑大量的请求时将端口占满了。
修改注册表解决该问题:https://support.microsoft.com/zh-cn/help/196271/when-you-try-to-connect-from- tcp-ports-grea ter-than-5000-you-receive-t
- cmd 中,用 regedit 命令打开注册表
- 在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 下,
- 右击 parameters,添加一个新的 DWORD,名字为 MaxUserPort
- 然后双击 MaxUserPort,输入数值数据为 65534,基数选择十进制(如果是分布式运行的话,控制机器和负载机器都需要这样操作)
- TCPTimedWaitDelay:30【同上方法配置】
- 修改配置完毕之后记得重启机器才会生效
性能监控
JVM 内存模型
程序计数器 Program Counter Register:
- 记录的是正在执行的虚拟机字节码指令的地址
- 此内存区域是唯一一个在 JAVA 虚拟机规范中没有规定任何 OutOfMemoryError 的区域
虚拟机:VM Stack
- 描述的是 JAVA 方法执行的内存模型,每个方法在执行的时候都会创建一个栈帧, 用于存储局部变量表,操作数栈,动态链接,方法接口等信息
- 局部变量表存储了编译期可知的各种基本数据类型、对象引用
- 线程请求的栈深度不够会报 StackOverflowError 异常
- 栈动态扩展的容量不够会报 OutOfMemoryError 异常
- 虚拟机栈是线程隔离的,即每个线程都有自己独立的虚拟机栈
本地方法:Native Stack :本地方法栈类似于虚拟机栈,只不过本地方法栈使用的是本地方法
堆:Heap:几乎所有的对象实例都在堆上分配内存
MetaSpace:直接操作物理内存
堆
所有的对象实例以及数组都要在堆上分配。堆是垃圾收集器管理的主要区域,垃圾回收,回收的就是Heap(堆)区,也被称为“GC 堆”;也是我们优化最多考虑的地方。
堆可以细分为:
新生代
- Eden 空间
- From Survivor 空间
- To Survivor 空间
老年代
永久代/元空间:Java8 以前永久代,受 jvm 管理,java8 以后元空间,直接使用物理内存。因此, 默认情况下,元空间的大小仅受本地内存限制。 从 Java8 开始,HotSpot 已经完全将永久代(Permanent Generation)移除,取而代之的是一 个新的区域—元空间(MetaSpace)
GC图
FullGC非常慢,后来优化监控时,一定要注意避免应用经常性发生FullGC
YGC就是MinorGC
性能监控—jconsole 与 jvisualvm
Jdk 的两个小工具 jconsole、jvisualvm(升级版的 jconsole);通过命令行启动,可监控本地和远程应用。远程应用需要配置。jvisualvm相当于升级版本的jconsole,它俩用哪一个都行。
jconsole
jvisualvm能干什么
监控内存泄露,跟踪垃圾回收,执行时内存、cpu 分析,线程分析…
- 运行:正在运行的
- 休眠:sleep
- 等待:wait
- 驻留:线程池里面的空闲线程
- 监视:阻塞的线程,正在等待锁
jvisualvm安装插件方便查看 gc
cmd 查看自己的 jdk 版本
打开网址 https://visualvm.github.io/pluginscenters.html,找到对应的
复制下面查询出来的链接:https://visualvm.github.io/uc/8u131/updates.xml.gz
jvisualvm的插件VisualGC的界面
中间件监控指标
- 当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下,线 程数最小值设置 50 和最大值设置 200 比较合适。
- 当前运行的 JDBC 连接数不能超过设定的最大值。一般情况下系统性能较好的情况下, JDBC 最小值设置 50 和最大值设置 200 比较合适。
- GC频率不能频繁,特别是 FULL GC 更不能频繁,一般情况下系统性能较好的情况下, JVM 最小堆大小和最大堆大小分别设置 1024M 比较合适。
数据库监控指标
- SQL 耗时越小越好,一般情况下微秒级别。
- 命中率越高越好,一般情况下不能低于 95%。
- 锁等待次数越低越好,等待时间越短越好。
压力测试表格
修改SpringBoot微服务内存参数:
参考
雷丰阳: Java项目《谷粒商城》Java架构师 | 微服务 | 大型电商项目.
本文完,感谢您的关注支持!
标签:13,请求,压测,雷丰阳,并发,线程,内存,监控,jvisualvm From: https://blog.csdn.net/weixin_44018671/article/details/129523901