【性能测试总结】

性能优化总结：
1，数据库配置增大table_cache，增加表缓存大小，增大join_buffer_size连接池大小
1)
show global variables like ‘table%cache%’;
set global table_definition_cache=2000;
set global table_open_cache=300000;
2)
show variables like ‘%buffer%’;
set join_buffer_size = 4294967168;
2, 尽量避免LIKE %xxx%查询
STRU_PATH LIKE CONCAT( ‘%’, ‘S0000000000000000002’, ‘%’ ) 这种%在前的会导致索引失效，可以使用以下两种方式
1)AND instr( STRU_PATH, ‘S0000000000000000002’ )
2)AND STRU_PATH in (select STRU_PATH from PUB_STRU where STRU_PATH LIKE CONCAT( ‘%’, ‘S0000000000000000002’, ‘%’ ) )
3,避免for循环中调用数据库查询，如果有业务需求，可以通过一次性查询全部数据将数据查出来，再从for循环中通过stream流之类的方式处理。
4,可视化前端页面避免引入不必要的js和css文件，文件的渲染需要时间

排查流程：
首先查看接口返回时间定位是前端渲染慢还是接口查询慢
1）喧染慢
a.如果是渲染慢需要排查是否进入了过多不必要的js和css
b.排查是不是某个方法慢，方法慢则需要具体优化js的方法，或者转为后台处理，浏览器的处理不如服务器快
2）接口慢
a.接口慢大概率是因为查询慢，首先查看是不是因为某个sql的原因，如果是涉及的表比较多可以考虑增大数据库对应的配置
b.优化代码：for循环中尽量避免查询数据库，当循环的体量比较大的时候会不可避免的多次查询，可以通过一次性查询全部数据将数据查出来，再从for循环中通过stream流之类的方式处理。fori的运算速度要比foreach效率高。视情况而定使用逻辑分页还是物理分页，理论上物理分页会更好。不可避免多表联查的话可以考虑拆分sql然后在代码中通过Stream流的方式拼接结果集
c.优化sql：排查是否是由于某一条sql导致的查询慢，可以打印查询时间，或者将sql在数据库工具中执行，优化时可以使用索引，并且避免出现索引失效的情况，减少sql的函数运算等
3）排查是否tomcat配置的内存太小，导致虚拟机慢，可以适量增大jvm的内存大小
4）排查服务器性能，巧妇难为无米之炊，服务器的配置低，优化解决不了实际问题
5）总之按规范开发保证代码质量是性能的前提条件，开发时避免出现慢sql等，写代码时考虑数据量大的兼容性。