压力测试 及jvm 优化
堆：堆中存放的是对象
新生代 和老年代 新生代: eden 区 和 s1 s2区 老年代: 如果对象较大 放不进Eden区 那么会进行一次youngGC 再次放入 如果还是放不进eden区 那么就会放入old区， 经过youngGC幸存下来的对象 会进入s1 区 每次经过youngGC 如果s1 还存活 那么s1的对象会进入s2 s2中的对象会进入s1 每次年龄+1 如果超过阈值 那么就会进入老年代 在放入old 区时 还是会判断 该对象是否能放入old区 如果放不下, 先进行一次fullGC,(fullGC是针对所有堆中的对象进行GC) 再次放入old区 优化点 JVM防止频繁的fullGC
jvisualvm
添加插件。如果插件不可用，那么需要更新
https://visualvm.github.io/pluginscenters.html 需要结合你的jdk的版本来选择对应的插件的版本
我们需要查看每一个组件（中间件） 所花费的时间是多少 性能高低
此时设置线程组
查看聚合报告
docker stats 查看各个容器 在发送请求时 的参数 发现nginx 的网络io高 而block IO 却没有
gateWay网关压测
直接输入网关的地址
查看cpu和堆的使用情况
Gc 的使用情况
设置网关最大运行内存
设置product 使用内存
在product服务中创建一个简单的接口访问 @RequestMapping("/hello") @ResponseBody public String Hello(){ return "hello"; }
然后复制地址到jmeter 上去压测
以上发现 单独访问 每个服务访问速度还是可以的
那么我们来测试 nginx +gateway 效果怎么样
这里我们发现吞吐量快速降低
解决方法
此时访问没有添加索引的字段 parent_cid 时间花费3毫秒
此时查询慢了1毫秒
此时我们用jmeter查看聚合参数
发现在impl 根据某个字段查找时 若该字段不是索引字段 添加数据库的索引字段效果 检索效率会有一定的提升
通过上面的压力测试我们可以发现如果后端服务及处理动态请求又处理静态请求那么他的吞吐量是非常有限的，这时我们可以把静态资源存储在Nginx中。
将静态文件打包成zip格式 C:\Users\Administrator\msb-mall\mall-product\src\main\resources\static
然后用文件传输到linux 系统中
然后执行命令 6d3是容器nginx 的id 解压文件
docker cp ./index 6d3:/usr/share/nginx/html/static
docker exec -it mynginx /bin/bash
进入docker
说明静态资源已经放进nginx中了
然后我们删掉项目中的静态资源 为了以防万一 记得先备份静态资源
在index.html中 ctrl+shift+R 替换掉模板路径
然后我们进入到nginx 中的/etc/nginx/conf.d文件中
vim mall.conf
在nginx 配置文件中指定static 开头的请求处理方式
保存退出 重启nginx 我们发现访问mallmsb.com 可以正常访问了 但是如果直接去访问服务的index.html页面 就会加载不到静态资源了
因为直接访问 不会经过nginx 自然找不到静态文件static
ps:
JMeter Address 端口占用的问题 搜索之后发现需要在regedit中添加注册表项MaxUserPort，TcpTimedWaitDelay重启一下就可以解决了。 解决方法： 打开注册表：ctrl+r 输入regedit 进入注册表，路径为：\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 新建DWORD值，（十进制）设置为30秒。名称:TcpTimedWaitDe,值:30 新建DWORD值，（十进制）最大连接数65534。名称:MaxUserPort,值:65534 修改完成后重启生效
ps:
当系统出现outofmemerary 时应怎么调整jvm 参数
-Xms 最小堆内存大小
-Xmx 最大堆内存大小
-Xmn 年轻代大小
整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小
-Xss128k 每个线程堆栈的大小 不要轻易设置
---------------------------------------------------------------------------------------------------
-XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4
-XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5
-XX:MaxPermSize=n:设置持久代大小
收集器设置
-XX:+UseSerialGC:设置串行收集器
-XX:+UseParallelGC:设置并行收集器
-XX:+UseParalledlOldGC:设置并行年老代收集器
-XX:+UseConcMarkSweepGC:设置并发收集器
垃圾回收统计信息
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename
并行收集器设置
-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
并发收集器设置
-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
-XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。
调优总结 年轻代大小选择 响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。 吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。 年老代大小选择 响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。
如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得： 并发垃圾收集信息 持久代并发收集次数 传统GC信息 花在年轻代和年老代回收上的时间比例 减少年轻代和年老代花费的时间，一般会提高应用的效率 吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。 较小堆引起的碎片问题 因为年老代的并发收集器使用标 记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。
但是，当堆空间较小时，运行一段时间以后， 就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如 下配置： -XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。 -XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩
浙公网安备 33010602011771号