首先附上apache-jmeter-5.4.1安装包(官网下载有点慢哈)链接: https://pan.baidu.com/s/1s7FQRfRPHsCXTKz9KyQQJg
提取码: fvnf
一.jemeter安装使用
1.将压缩包解压后在bin目录运行jmeter.bat设置语言国际化
2.在默认的测试计划中创建测试线程组
3.在刚创建的线程组下添加取样器测试HTTP请求
GET请求
压力测试的接口
4.在线程组下添加监听器用于查看压测接口的相关指标报告
5.启动压测线程组
保存测试计划,方便下次直接运行
6.压测结束后查看压测指标报告
7.清除全部指标报告,测试你自己写的接口吧
POST请求
post内容编码设置
请求头管理
*备注:出现中文乱码解决方案
方案一
-
进入Jmeter的bin目录下,找到jmeter.properties文件,以文本形式打开
-
找到sampleresult.default.encoding这个参数,此行默认是注释的(同时可以看到默认编码格式为ISO-8859-1)
-
复制此行将注释去掉,并将编码格式设置为UTF-8
-
重启jmeter生效(一定要重启)
方案二
或者在http请求中添加后置处理器输入 prev.setDataEncoding(“UTF-8”);
设置请求编码格式:
二.性能监控jvisualvm使用
通过对某个接口的压力测试可以得到这个接口的性能报告,然后通过这个报告可以衡量这个接口符不符合我们当前的要求,如果不符合性能要求,就需要对接口进行性能优化!
1.影响性能考虑点包括:
1).首先要考虑自己的应用是属于cpu密集型还是io密集型
2).①数据库②应用程序③中间件(nginx getway Tomcat…)④网络和操作系统等方面
2.在使用jvisualvm前需要先了解关于jvm的堆内存和垃圾回收机制
1)jvm内存模型
2)堆:所有对象实例以及数组都要在堆上分配,推是垃圾收集器主要管理的区域也被称为GC;堆也是最多考虑需要优化的地方
推可以细分为:
- 新生代
- Eden空间
- From Survivor空间
- To Survivor空间
- 老年代
- 永久代/元空间
- java8以前永久代受jvm管理,java8以后元空间,直接使用物理内存,因此默认情况下元空间的大小受本地内存限制
3)垃圾回收gc
3.进入cmd键入jvisualvm指令进入jvm监控台
1)安装visual GC插件垃圾回收监控台
点击工具–>插件
选中点击左下角的安装即可(我这里已经安装过了),安装完成以后退出监控台重新进入插件即可生效
2)jvisualvm能干什么?
检测内存泄漏,跟踪垃圾回收,执行时内存,cup分析,线程分析
- 运行:正在运行的
- 休眠:sleep
- 等待:wait
- 驻留:线程池里面的空闲线程
- 监视:阻塞的线程,正在等待锁
三.优化中间件对性能的影响
1.压测nginx
1)访问虚拟机上的nginx默认首页
2)docker stats 查看cpu使用率内存等
3).开始压测
压测进行时的nginx的cpu使用情况:发现比较浪费cpu内存占用很低, 因为他主要需要更多的线程去处理请求,cpu要来回在线程之间切换计算
从压测指标报告中可以得出:
2.压测网关
1)可以看出网关也比较浪费cpu,网关功能和nginx基本是差不多的
2)如果eden space的大小改变,gc时间减少,就又会将吞吐量提升
3)指标报告
3.压测简单服务
1)写一个简单服务,没有页面渲染,也不操作数据库
@ResponseBody
@GetMapping("/hello")
public String hello(){
return "hello";
}
2)开始压测
3)指标报告
4.压测gateway+简单服务
1)现在想看Gateway加简单服务的压测,gateway除了映射/api/product 以外,还来映射/hello请求,因为不是api请求,也不用截串
- id: product_route
uri: lb://gulimall-product
predicates:
- Path=/api/product/**,/hello
filters:
- RewritePath=/api/(?<segment>/?.*), /$\{segment}
2)开始压测
3)指标报告
5.压测nginx+gateway+简单服务
1)开始压测
2)指标报告
压测到这里可以得出一个结论:中间件越多,性能损失越大,大多都损失到网络交互了
6.压测首页渲染
1)开始压测
2)指标报告
7.压测首页渲染(开启thymeleaf缓存)
1)在配置文件中开启thymeleaf缓存,重启服务
2)压测指标报告,可以看出开启缓存可以提高吞吐量
8.压测首页渲染(开缓存/优化数据库/关日志)
1)在配置文件中开启thymeleaf缓存并关闭日志打印,重启服务
# 开启thymeleaf缓存
thymeleaf:
cache: true
#设置日志级别,打印出SQL语句
logging:
level:
com.atguigu.gulimall.product: error
2)优化数据库-创建索引
3)指标报告
可以看出吞吐量进一步提升!
9.压测首页渲染全部数据(开缓存/优化数据库/关日志)
1)开始压测
首页渲染全部数据–html中引入的全部静态资源
2)指标报告
由此可见主要慢在了静态资源上!静态资源的请求占用了Tomcat的很多资源导致了吞吐量急骤下降
10.首页渲染全部数据(nginx/gateway/开缓存/优化数据库/关日志/动静不分离)&&首页渲染全部数据(nginx/gateway/开缓存/优化数据库/关日志/动静分离)
1)引入动静分离是将项目的静态资源放在nginx里面,由于上面的压测首页渲染测试使用的localhost并未将nginx加入进来,所以这里先压测首页渲染全部数据(nginx/gateway/开缓存/优化数据库/关日志/动静不分离)
然后再压测首页渲染全部数据(nginx/gateway/开缓存/优化数据库/关日志/动静分离)
这样可以对比出效果!
2)首页渲染全部数据-动静不分离开始压测
3)指标报告
由此可见和压测8相比,加入了nginx和gatew吞吐量有下降了;下面来看看实现动静分离的效果!
4)动静分离压测
4.1 /static/**所有请求都有nginx直接返回,tomcat就不需要分一些线程来处理静态资源了可以进一步提高吞吐量!
4.2 在虚拟机中nginx的挂载目录下创建static文件夹
4.3 将index静态资源 剪切 到虚拟机的static文件夹下
4.4 关闭thymeleaf缓存重启项目,所有静态资源都无法访问了,这时候需要安照该路径配置nginx,让nginx找到这些静态资源
4.5 配置nginx动静分离
cd /mydata/nginx/conf/conf.d/
vi gulimall.conf
加入下面配置
location /static/ {
root /usr/share/nginx/html;
}
静态资源都到/nginx/html文件下找;动态请求负载均衡到我们的后台服务
4.6 保存配置文件重启nginx服务,nginx加载静态资源完成
6.7 开启缓存重启服务,进行首页渲染全部数据–动静分离压测
6.8 指标报告
吞吐量有上一次对比压测的7吞吐量上升到32吞吐量了,进入jvisualvm监控台看发现现在慢的主要原因是在老年代的gc上,而不是nginx动静分离了
没过多久发现jemeter控制台报错了,内存溢出服务崩溃!
于是重新给jemeter和要启动的服务分配了内存
进入JMeter的bin路径,找到JMeter的启动文件
编辑jmeter.bat,修改set HEAP的值(-Xms是初始内存,-Xmx是最大占用内存);
给启动的服务分配内存:
最大和初始内存都固定为1024m; -Xmn512m新生代去调整为512m;目的是让他不进行频繁的垃圾回收
-Xmx1024m -Xms1024m -Xmn512m
分配完成重启服务再来进行压测
通过压测结果发现nginx动静分离明显提高吞吐量,现在的tomcat只处理动态请求,占用的资源就会很小了!
压力测试表
压测内容 | 压测线程数 | 吞吐量/s | 90%响应时间 | 99%响应时间 |
---|---|---|---|---|
nginx | 50 | 6500 | 6 | 117 |
gateway | 50 | 21128 | 3 | 9 |
简单服务 | 50 | 38408 | 2 | 6 |
gateway+简单服务 | 50 | 9759 | 12 | 32 |
nginx+gateway+简单服务 | 50 | 1074 | 64 | 105 |
首页渲染 | 50 | 631 | 103 | 348 |
首页渲染(开启thymeleaf缓存) | 50 | 686 | 93 | 335 |
首页渲染(开缓存/优化数据库/关日志) | 50 | 2088 | 32 | 162 |
首页渲染全部数据(开缓存/优化数据库/关日志) | 50 | 10 | 3747 | 17797 |
首页渲染全部数据(nginx/gateway/开缓存/优化数据库/关日志/动静不分离) | 50 | 7 | 4259 | 18148 |
首页渲染全部数据(nginx/gateway/开缓存/优化数据库/关日志/动静分离) | 50 | 63 | 1191 | 1591 |
三级分类数据获取 | 50 | 31 | 2355 | 2848 |
三级分类获取获取(优化业务) | 50 | 331 | 216 | 450 |
三级分类获取获取(优化业务/使用redis) | 50 | 1942 | 34 | 52 |