1、测试目的
通过hero_mall项目的性能和负载的瓶颈分析，对于Java体系知识有系统的发现与认识，通过对比优化前后对比展示技术的价值
性能指标关系
2、测试工具
Jmeter测试、Grafana+Prometheus+node_exporter+InfluxDB数据展示
3、测试环境
3.1、环境
| 指标 | 参数 |
|---|---|
| 机器 | 4C8G |
| 集群规模 | 单机 |
| hero_mall版本 | 1.0 |
| 数据库 | 4C8G |
| 带宽 | 100Mbps |
3.2、启动命令
java -jar hero_web-1.0-SNAPSHOT-default.jar --spring.application.location=/usr/local/hero/application-dev.yml
## application-dev.yml
server:
port: 9001
spring:
thymeleaf:
cache: false
datasource:
driver-class-name: com.mysql.jdbc.Driver
url: jdbc:mysql://116.204.x.x:3306/hero_all?useUnicode=true&characterEncoding=UTF-8&serverTimezone=GMT%2B8
username: root
password: 123456
# Tomcat的maxConnections、maxThreads、acceptCount三大配置，分别表示最大连接数，最大线程数、最大的等待数，可以通过application.yml配置文件来改变这个三个值，一个标准的示例如下：
server.tomcat.uri-encoding: UTF-8
# 思考问题：一台服务器配置多少线程合适？
server.tomcat.accept-count: 1000
# 等待队列最多允许1000个请求在队列中等待
server.tomcat.max-connections: 20000
# 最大允许20000个链接被建立
## 最大工作线程数，默认200, 4核8g内存，线程数经验值800
server.tomcat.threads.max: 800
# 并发处理创建的最大的线程数量
server.tomcat.threads.min-spare: 100
# 最大空闲连接数，防止突发流量
management:
endpoints:
web:
exposure:
include: "*"
base-path: /actuator
4、测试场景
验证hero_mall服务获取商品信息接口在不同并发规模的表现
setting01
-模拟低延时场景，用户访问接口并发逐渐增加的过程。接口的响应时间为20ms，线程梯度：5、10、15、20、25、30、35、40个线程，5000次;
时间设置：Ramp-up period(inseconds)的值设为对应线程数
测试总时长：约等于20ms x 5000次 x 8 = 800s = 13分
setting02
-模拟低延时场景，带宽减少为25Mbps的过程。接口的响应时间为20ms，线程梯度：5、10、15、20、25、30、35、40个线程，5000次;
时间设置：Ramp-up period(inseconds)的值设为对应线程数
测试总时长：约等于20ms x 5000次 x 8 = 800s = 13分
setting03
-模拟高延时场景，用户访问接口并发逐渐增加的过程。接口的响应时间为500ms，线程梯度：100、200、300、400、500、600、700、800个线程，200次;
时间设置：Ramp-up period(inseconds)的值设为对应线程数的1/10；
测试总时长：约等于500ms x 200次 x 8 = 800s = 13分
setting04
-模拟高延时场景，tomcat线程数调整为800的过程。接口的响应时间为500ms，线程梯度：100、200、300、400、500、600、700、800个线程，200次;
时间设置：Ramp-up period(inseconds)的值设为对应线程数的1/10；
测试总时长：约等于500ms x 200次 x 8 = 800s = 13分
setting05
-模拟高延时场景，容器优化Tomcat升级Undertow的过程。接口的响应时间为500ms，线程梯度：100、200、300、400、500、600、700、800个线程，200次;
时间设置：Ramp-up period(inseconds)的值设为对应线程数的1/10；
测试总时长：约等于500ms x 200次 x 8 = 800s = 13分
// TODO
setting06
-模拟低延时场景，数据库SQL调优的过程。接口的响应时间为20ms，线程梯度：5、10、15、20、25、30、35、40个线程，5000次;
// TODO
setting07
-模拟低延时场景，JVM调优的过程。接口的响应时间为20ms，线程梯度：5、10、15、20、25、30、35、40个线程，5000次;
5、核心接口测试结果
5.1、涉及接口
获取商品信息接口，目标峰值TPS：10000，P99响应时间：300ms
/spu/goods/10000023827800 1.1k
/spu/goods/10000005620800 3.8k
Active Threads：注意压力机的活动线程数并不等同于在线用数中，并发的用户数。压力活动线程数是用来模拟用户发出并发请求的操作。
TPS：每秒处理事务数
RT：响应时间
5.2、测试结果
setting01
聚合报告
Active Threads
RT
TPS
Grafana
CPU
小结：
忽略30thread数据，因是本机启动jmeter，测试30thread期间打开直播回放，影响带宽导致请求数据慢吞吐量下降
请求响应较快，平均rt在35左右，异常率比较低忽略30thread吞吐量平均在六百到七百间
setting02
聚合报告
Active thread
RT
TPS
Grafana
CPU
NET-IO
小结：
25Mbps带宽下，与之前100Mbps带宽下网络速度要高，可能受限于华为云所在区域的网络质量，不受服务器设置参数决定
测试结果中RT响应长的节点与TPS变化曲线基本吻合，且与grafana和华为云自己的网络监控趋势也大致一样，测试异常样本受当时网络质量影响
21ms接口吞吐量可达800，与后续500ms请求指标对比效果明显
setting03
聚合报告
Active Threads
RT
TPS
grafana
CPU
小结：
TPS下降，异常率上升，数据传输速度慢，为实现相同TPS服务端所需的线程数变大
应该是服务端的线程数限制吞吐量，后续调整Tomcat线程数对比
setting04
聚合报告
Active Threads
RT
TPS
Grafana
CPU
小结：
相比较调整线程数前，吞吐量提升明显，平均响应时间提升明显，异常率大大减低，接收速度提升明显，性能优化效果明显
setting05
聚合报告
Active Threads
RT
TPS
Grafana
CPU
小结：
提升与Tomcat修改线程数类似，效果要稍微比tomcat调整线程数好一些，也有可能是晚上网络好一些的缘故，都属于比较有效的提升高延迟请求的吞吐量与响应时间
6、测试结论
hero_web性能测试针对不同场景对比，总结了相关性能优化解决方案
减少请求数据量，或提升带宽，降低网络带宽瓶颈影响
根据硬件设备及业务场景所需调整后端容器线程数，提升吞吐量
调整后端服务容器并设置合适线程数，提升吞吐量
调整后端容器IO模型（NIO/AIO/NIO2）,提升吞吐量
合理运用浏览器缓存、openstry（代理层缓存）、分布式缓存（redis等）降低mysqlIO瓶颈
慢sql调优，合理设置索引、复杂查询的优化处理（解释执行过程、排序等聚合操作合理选择和避免等）
jvm参数调优，使用最少的设备提升最大的性能
