影响性能的因素
影响性能的因素包括：数据库、应用程序（编码能否优化）、中间件（tomcat、nginx等（本人项目是访问nginx->SpringCloudGateway->tomcat））、网络带宽、操作系统等
首先考虑自己的应用是CPU密集型（大量计算）还是IO密集型（内存占用高、磁盘读写多、网络流量大）
优化的方式
我们主要是要优化运行时数据区（方法区、堆、虚拟机栈、本地方法栈、程序计数器），再详细一点即最主要优化 堆（新生代、老年代）
尽量避免fullGC，因为fullGC会比YGC慢很多
内存观察
为了方便对压力测试期间，观察jvm内存的变化我们使用如下操作来更方便观察jvm
打开cmd命令 使用 jvisualvm命令对运行的程序进行分析
点击菜单栏 工具-》插件。点击更新，如果有503错误则继续如下操作，没有则忽略
1、打开链接 https://visualvm.github.io/pluginscenters.html
2、cmd命令行，java -version 查看自己jdk版本 ，在链接中找到自己版本对应的jdk，点击对应jdk版本下方的链接，复制打开的新页面顶部的链接
3、回到jvisualvm的图形化界面，点击设置，点击编辑，将url替换
4、重启jvisualvm打开visual GC，对对应的信息进行查看
在图上，我们可以看到在新生代发生了2106次gc，仅6.288s，而在老年代仅发生3次gc就用了0.419312s，故我们要尽量避免fullgc
压力测试
中间件对性能的影响
Nginx压测
1、测试Nginx的性能
添加线程组，50个线程，不断请求，永不停止
因我nginx使用docker容器部署，故在docker容器中使用docker stats 查看nginx的cpu及io占用
2、启动JMeter
3、在容器中查看nginx的相关资源占用，发现nginx使用的CPU比较多
SpringCloud Gateway压测
启动JMeter后使用jvisualvm对网关应用进行资源占用分析，发现gateway也是对cpu资源占用较高
商品服务压测
首先单测简单服务（使用控制器直接返回hello，不做运算也不对数据库操作），发现即使内存分配的很低的情况下，性能也是十分高的
从网关到简单服务压测
使用网关（吞吐量1w/s左右）转发至商品服务（吞吐量1w/s左右）的压力测试，此时吞吐量是3k左右，性能损失较大，简单得出中间件越多，性能损失越大，大多损失在网络交互
从nginx到gateway到商品服务全链路压测
此时的吞吐量只到了800左右
数据库、渲染数据等对性能影响
直接访问商品服务首页一级菜单渲染压测
一级菜单需要访问数据库进行查询，并对结果进行封装，此时只有270左右的吞吐量
直接访问商品服务首页三级菜单渲染压测
此时需要去数据库查询的数据较多，吞吐量只有2了
上表可以反应性能损失，但因为我是在同一台机器上进行压测，线程间有竞争，故结果仅供参考，但也能反应出各类问题
商品首页全量压测（js，css，img）
首先设置Jmeter，压测后发现吞吐量只有7左右，新生代及老年代的内存太小
优化后全量压测
中间件越多，性能损失越大，大多损失在网络交互
业务： DB（MySQL优化）、模板的渲染速度（缓存，CPU）、静态资源
优化
动静分离
计划：
1、将所有项目的静态资源都放在nginx中
2、规则：/static/***所有请求都有nginx直接返回
行动：
1、将服务中的/static文件夹复制到nginx中html/static 文件夹
2、删除项目中的static文件夹
3、更改前端页面请求资源的路径，所有请求静态资源的链接前(图片,css,js等)加上/static，（由/index/css/a.css 改为 /static/index/css/a.css）
4、再在nginx配置文件中修改 cd /mydata/nginx/conf/ vi对应的conf, 修改配置
server{
listen 80;
server_name amal.com;
location /static/ {
root /usr/share/nginx/html;
}
location / {
proxy_set_header Host $host;
proxy_pass http://amall;
}
}5、访问原来商城中的页面：访问成功
此时再进行全量压测，吞吐量从之前的7变成了11左右，再看看堆内存占用情况，发现老年代几乎要满，新生代也在不停gc，时间大多花在gc上
调优
1、调大jvm内存，从100m调至1024m -Xmx1024m(最大可占用内存) -Xms1024m(启动时占用内存) -Xmn512m(新生代大小)
2、业务逻辑调优
2.1将数据库的多次查询变成一次 吞吐量变成130左右
