现状:交易接口,并发10笔每秒都不能100%超过,存在响应超时或者连接超时,但服务节点看着很正常没有任何错误信息,太夸张了
服务:测试环境/spring cloud/mysql linux 4*16G/nacos/单节点/固定带宽5M
- 准备一个模拟方法,无需任何操作,测试并发,排除业务内部逻辑,发现有两个aop校验请求对象,校验参数:非空/长度/正则等,做的工作都一样
- java 服务的CUP占很少10%不到,但mysqld占CUP很高300%,应该是SQL问题,挨个相关SQL检查,发现有两处优化的地方,一个是查询商户信息,查询了很多接口没有用到的表,增加一个方法,只取有需要的数据,另外一个接口没有加索引,解决这两个地方mysqld的CUP立马就下来了
- 并发加到50~貌似没什么变化,依旧会出现响应超时或者连接超时,把带宽改成弹性50M,服务基本上正常了,并发200~500 也不会出现响应超时或者连接超时的情况
- 观察日志
- 调整数据库连接池
- 开启gzip
- 进一步优化(网关跑一星期左右内存持续增高),测试环境压测、结合jconsole和visualvm,观察堆内存变化情况,当内存溢出的时候Heap Dump(生成hprof文件,可用visual或者idea 打开观察) ,分析内存对象,看下占用内存高的主要的哪些对象,最后发现网关每次都去存取一次(用户基本信息、用户加入的机构信息、系统产品/菜单信息、用户机构权限等),其中系统产品/菜单信息、用户机构权限数据量较大,采用按需获取,再次压测明显有效果,另外用户每次登录都生成一个新token ,有必要可以采取单点登录