系统性能压力测试
一、压力测试
压力测试是给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷，是通过搭建与实际环境相似的测试环境，通过测试程序在同一时间内或某一段时间内，向系统发送预期数量的交易请求、测试系统在不同压力情况下的效率状况，以及系统可以承受的压力情况。然后做针对性的测试与分析，找到影响系统性能的瓶颈，评估系统在实际使用环境下的效率情况，评价系统性能以及判断是否需要对应用系统进行优化处理或结构调整。并对系统资源进行优化。
在压力测试中我们会涉及到相关的一些性能指标：
- 响应时间(Response Time:RT):从客服端发送请求开始到获取到服务器的响应结果的总的时间
- HPS(Hits Per Second):每秒点击的次数
- TPS(Transaction Per Second):系统每秒处理的交易数，也叫会话次数
- QPS(Query Per Second):系统每秒处理查询的次数
在互联网企业中，如果一个业务有且仅有一个请求连接，那么TPS=QPS=HPS的，而在一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询的次数，用HPS来衡量服务器单击请求。
我们在测试的时候就会通过这些指标(HPS,TPS,QPS)的数据来衡量系统的系统，指标越高说明系统性能越好，在一般情况下，各个行业的指标范围有着比较大的差异，下面简单的列举了下，仅供参考
- 金融行业:1000TPS~50000TPS
- 保险行业:100TPS~100000TPS
- 制造业：10TPS~5000TPS
- 互联网大型网站:10000TPS~1000000TPS
- 互联网其他:1000TPS~50000TPS
当然我们还会涉及到一些其他的名词，如下：
| 名词 | 说明 |
|---|---|
| 最大响应时间 | 用户发出请求到系统做出响应的最大时间 |
| 最少响应时间 | 用户发出请求到系统做出响应的最少时间 |
| 90%响应时间 | 指所有用户的响应时间进行排序，第90%的响应时间 |
当我们从外部来看，性能测试主要要关注这三个性能指标
| 指标 | 说明 |
|---|---|
| 吞吐量 | 每秒钟系统能够处理的请求数，任务数 |
| 响应时间 | 服务处理一个请求或一个任务的耗时 |
| 错误率 | 一批请求中结果出错的请求所占的比例 |
二、JMeter
1.安装JMeter
官网地址：https://jmeter.apache.org/download_jmeter.cgi 下载后解压即可，然后进入到bin目录下双击 JMeter.bat文件即可启动
该工具支持中文
中文后的页面
2.JMeter基本操作
2.1 添加线程组
线程组的作用就是定义任务的相关属性，比如每秒执行多少线程，重复多少次该操作
2.2 取样器
在定义了线程组后，我们得继续定义每个线程的操作行为，也就是创建对应的取样器，在取样器中我们定义要访问的服务的协议及地址信息。
然后我们需要在取样器中定义服务的信息
2.3 监视器
在取样器中我们定义了要访问的服务信息，然后我们就要考虑请求后我们需要获取任务的相关的指标信息。这时就用到了监视器。
对应的结果数据有 查看结果树 汇总报告 聚合报告 ，查看结果对应的图形 汇总图 …
2.4 测试百度
写好了取样器后，启动测试。
启动后我们就可以查询测试的结果数据
2.5 测试商城首页
启动后查看对应的结果
2.6 JMeter Address 占用的问题
搜索之后发现需要在regedit中添加注册表项MaxUserPort，TcpTimedWaitDelay重启一下就可以解决了。
解决方法：
打开注册表：ctrl+r 输入regedit
进入注册表，路径为：\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
新建DWORD值，（十进制）设置为30秒。名称:TcpTimedWaitDe,值:30
新建DWORD值，（十进制）最大连接数65534。名称:MaxUserPort,值:65534
修改完成后重启生效
三、性能优化
1.考虑影响服务性能的因素
数据库、应用程序，中间件(Tomcat,Nginx),网络和操作系统等
我们还得考虑当前的服务属于
- CPU密集型：计算比较影响性能—>添加CPU，加机器
- IO密集型：网络IO，磁盘IO，数据库读写IO，Redis读写IO --》缓存，加固态硬盘，添加网卡
2.JVM回顾
设置JVM参数，适当调整相应的堆空间的内存大小，也是提升效率的一个关键动作，本地环境idea中，配置启动环境，VM Options参数即可 -Xmx512m -Xmn512m
而运行生产环境，那么配置jvm参数，通过java -Xmx512 -Xmn512m xxx.jar
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-s4RvI9f0-1693209241788)(./images/1693****************208858173_image.png)]
JVM的内存结构
JVM中对象的存储和GC
1、JVM涉及的空间：堆：包括年轻代与老年代+字符串常量池，年轻代由一个Eden与两个Survivor区。方法区：持久代与元空间都是方法区的实现，JDK1.8改为元空间。
2、JVM参数设置，服务器配置的参数：
- -Xms：初始堆内存大小，设定程序启动时占用内存大小，默认物理内存1/64 -Xms = -XX:InitialHeapSiz
- -Xmx：最大堆内存，设定程序运行期间最大可占用的内存大小。如果程序运行需要占用更多的内存，超出了这个设置值，就会抛出OutOfMemory异常，默认物理内存1/4，-Xmx = -XX:MaxHeapSize。 上图中的-Xms与-Xmx设置的大小一样 6000M
- -Xss：设置单个线程栈大小，一般默认512~1024kb。单个线程栈大小跟操作系统和JDK版本都有关系，-Xss = -XX:ThreadStackSize
- -Xmn：设置年轻代大小。整个堆大小=年轻代大小 + 年老代大小 + 常量池。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8
- -XX:MetaspaceSize ：元空间大小，元空间本质跟永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于：元空间并不在虚拟机中，而是使用本地内存，由操作系统支配。因此，元空间大小仅受本地内存限制。
- -XX:+PrintGCDetails ：打印GC详细日志信息
- -XX:SurvivorRatio：幸存者比例设置，设置年轻代中Eden区与Survivor区的大小比值。设置为8，则两个Survivor区与一个Eden区的比值为2:8，一个Survivor区占整个年轻代的1/10
- -XX:NewRatio：新生代比例设置（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为1，则年轻代与年老代所占比值为1：1，年轻代占整个堆栈的1/2。
- -XX:MaxTenuringThreshold：进入老年代阈值设置
- -XX:PermSize=128m：持久代内存初始值分配128M； -XX:MaxPermSize=512m：设置持久代最大为512m
3.jconsole和jvisualvm
jconsole和jvisualvm是JDK自带监控工具。可以帮助我们更好的查看服务的相关监控信息，jvisualvm功能会更加的强大些。
3.1 jconsole
找到对应的进程
3.2 jvisualvm
因为是jdk6.0后自带的，我们同样的可以在cmd或者搜索框中找到
打开的主页面
找到对应的进程，双击进入
查看对应的监视信息
添加插件。如果插件不可用，那么需要更新
https://visualvm.github.io/pluginscenters.html 需要结合你的jdk的版本来选择对应的插件的版本
安装好之后重启jvisualvm即可
%
4. 中间件的性能
以下是一个完整的请求链路
然后我们来测试下相关的组件的性能
-
Nginx测试，可以直接方法默认的html页面，在nginx的配置文件中放置一个index.html文件，浏览器访问 nginx的默认地址去做压测，端口是默认80
-
初步得到测试后的一个情况，吞吐量等一些量化指标
-
接着我们可以把docke中的容器状态打开 docker stats命令，然后再次进行压测，实时观察 Nginx服务的性能变化判断CPU密集型是IO密集型，通过压测过程看到CPU飙升到满，可以判断是CPU密集型 可通过增加机器或CPU优化
-
其实也可以理解，因为Nginx不做业务处理，主要是做更多的请求的分发，创建更多子线程来进行维护，所以需要更多CPU支撑
-
网关测试：同哩访问所在服务器地址加相应端口直接访问，这里都没用具体的接口地址请求 和Nginx一样都是直接方法地址:端口，即可达到测试效果
-
单独测试服务：这里可以写一个简单的请求接口，直接返回一个字符串，不经过数据库数据，也就是针对应用服务的单独测试性能了
-
网关+服务：就是通过网关配置请求，做转发即可，请求的是网关服务的端口，然后会路由到具体服务去做请求相应
-
首页全量数据：这里涉及到一些静态资源的访问，那么就需要在jmeter工具中 高级设置去开启加载访问html资源，这样才能去访问到那些首页静态资源的图片，html,css,js等
| 压力测试内容 | 压力测试的线程数 | 吞吐量/s | 90%响应时间 | 99%响应时间 |
|---|---|---|---|---|
| Nginx | 50 | 7,385 | 10 | 70 |
| Gateway | 50 | 23,170 | 3 | 14 |
| 单独测试服务 | 50 | 23,160 | 3 | 7 |
| Gateway+服务 | 50 | 8,461 | 12 | 46 |
| Nginx+Gateway | 50 | |||
| Nginx+Gateway+服务 | 50 | 2,816 | 27 | 42 |
| 一级菜单 | 50 | 1,321 | 48 | 74 |
| 三级分类压测 | 50 | 12 | 4000 | 4000 |
| 首页全量数据 | 50 | 2 |
中间件越多，性能损失就越大，大多数的损失都是在数据的交互
简单的优化：
中间件：单个的效率都很高，串联的中间件越多，影响越大，但是在业务面前其实就比较微弱
业务：
- DB(MySQL，优化)
- 模板页面渲染
| 压力测试内容 | 压力测试的线程数 | 吞吐量/s | 90%响应时间 | 99%响应时间 |
|---|---|---|---|---|
| Nginx | 50 | 7,385 | 10 | 70 |
| Gateway | 50 | 23,170 | 3 | 14 |
| 单独测试服务 | 50 | 23,160 | 3 | 7 |
| Gateway+服务 | 50 | 8,461 | 12 | 46 |
| Nginx+Gateway | 50 | |||
| Nginx+Gateway+服务 | 50 | 2,816 | 27 | 42 |
| 一级菜单 | 50 | 1,321 | 48 | 74 |
| 三级分类压测 | 50 | 12 | 4000 | 4000 |
| 首页全量数据(DB-Themleaf) | 50 | 2 | ||
| 一级菜单(DB-索引) | 50 | 1900 | 40 | 70 |
| 三级分类压测(索引) | 50 | 34 | 1599 | 1700 |
| 首页全量数据(DB-Themleaf-放开缓存) | 50 | 30 | 。。。 | 。。。 |
5.Nginx实现动静分离
通过上面的压力测试我们可以发现如果后端服务及处理动态请求又处理静态请求那么他的吞吐量是非常有限的，这时我们可以把静态资源存储在Nginx中。
5.1 静态资源存储
把服务中的静态资源上传到Nginx服务中，把静态资源文件打成一个zip包，然后拖拽到Linux中，然后我们通过
unzip index.zip
来解压缩
然后替换掉模板文件中的资源访问路径
5.2 Nginx配置
然后我们在Nginx的配置文件中指定static开头的请求的处理方式
保存后重启Nginx服务，然后就可以访问了
6.三级分类优化
我们在获取三级分类的数据的时候，会频繁的操作数据库，我们可以对这段代码来优化
在此处我们可以一次查询出所有的分类数据，然后每次从这个一份数据中获取对应的信息，达到减少数据库操作的次数的目的，从而提升服务的性能。
/**
* 跟进父编号获取对应的子菜单信息
* @param list
* @param parentCid
* @return
*/
private List<CategoryEntity> queryByParenCid(List<CategoryEntity> list,Long parentCid){
List<CategoryEntity> collect = list.stream().filter(item -> {
return item.getParentCid().equals(parentCid);
}).collect(Collectors.toList());
return collect;
}
/**
* 查询出所有的二级和三级分类的数据
* 并封装为Map<String, Catalog2VO>对象
* @return
*/
@Override
public Map<String, List<Catalog2VO>> getCatelog2JSON() {
// 获取所有的分类数据
List<CategoryEntity> list = baseMapper.selectList(new QueryWrapper<CategoryEntity>());
// 获取所有的一级分类的数据
List<CategoryEntity> leve1Category = this.queryByParenCid(list,0l);
// 把一级分类的数据转换为Map容器 key就是一级分类的编号， value就是一级分类对应的二级分类的数据
Map<String, List<Catalog2VO>> map = leve1Category.stream().collect(Collectors.toMap(
key -> key.getCatId().toString()
, value -> {
// 根据一级分类的编号，查询出对应的二级分类的数据
List<CategoryEntity> l2Catalogs = this.queryByParenCid(list,value.getCatId());
List<Catalog2VO> Catalog2VOs =null;
if(l2Catalogs != null){
Catalog2VOs = l2Catalogs.stream().map(l2 -> {
// 需要把查询出来的二级分类的数据填充到对应的Catelog2VO中
Catalog2VO catalog2VO = new Catalog2VO(l2.getParentCid().toString(), null, l2.getCatId().toString(), l2.getName());
// 根据二级分类的数据找到对应的三级分类的信息
List<CategoryEntity> l3Catelogs = this.queryByParenCid(list,l2.getCatId());
if(l3Catelogs != null){
// 获取到的二级分类对应的三级分类的数据
List<Catalog2VO.Catalog3VO> catalog3VOS = l3Catelogs.stream().map(l3 -> {
Catalog2VO.Catalog3VO catalog3VO = new Catalog2VO.Catalog3VO(l3.getParentCid().toString(), l3.getCatId().toString(), l3.getName());
return catalog3VO;
}).collect(Collectors.toList());
// 三级分类关联二级分类
catalog2VO.setCatalog3List(catalog3VOS);
}
return catalog2VO;
}).collect(Collectors.toList());
}
return Catalog2VOs;
}
));
return map;
}
优化后的压测表现
| 压力测试内容 | 压力测试的线程数 | 吞吐量/s | 90%响应时间 | 99%响应时间 |
|---|---|---|---|---|
| Nginx | 50 | 7,385 | 10 | 70 |
| Gateway | 50 | 23,170 | 3 | 14 |
| 单独测试服务 | 50 | 23,160 | 3 | 7 |
| Gateway+服务 | 50 | 8,461 | 12 | 46 |
| Nginx+Gateway | 50 | |||
| Nginx+Gateway+服务 | 50 | 2,816 | 27 | 42 |
| 一级菜单 | 50 | 1,321 | 48 | 74 |
| 三级分类压测 | 50 | 12 | 4000 | 4000 |
| 三级分类压测(业务优化后) | 50 | 448 | 113 | 227 |
文章来源：https://www.toymoban.com/news/detail-687719.html
可以看到系统性能的提升还是非常明显的。文章来源地址https://www.toymoban.com/news/detail-687719.html
到了这里，关于【业务功能篇86】微服务-springcloud-系统性能压力测试-jmeter-性能优化-JVM参数调优的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
