性能优化分析

问题	原因	解决方案	备注
接口响应时间超出预期	慢sql、代码问题	1、慢sql：        1 优化sql语句；        2 查看对应数据表是否加索引；        3 数据量较大是根据实际业务场景考虑表分区(如经分事实表)。 2、代码问题：       1 调用预警接口查询时优化for循环，把循环查询改成批量查询；       2 SelectChildTreeList、aueryTreeTab级连查询导致IO响应超时；       3 权限部分加缓存。	查询慢SQL方法： 1、根据应用服务器日志的SQL起始和结束时间查看；                                 2、开启慢SQL查询日志，定义慢SQL时长
TPS低	1、网络带宽 2、连接池 3、垃圾回收机制 4、数据库配置 5、通信连接机制 6、硬件资源 7、压力机 8、压测脚本 9、业务逻辑 10、系统架构	1、网络带宽       在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争        ，间接导致服务端接收到的请求数达不到服务端的处理能力上限   2、连接池       可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池 3、垃圾回收机制       如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，对TPS也有影响，因为垃圾回收本身也需占用资源 4、数据库配置     高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引     没有绑定变量，抑或没有主从分离、读写分离等，导致事务处理过慢影响TPS 5、通信连接机制     串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。 6、硬件资源     包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等） 7、压力机     比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS：如负载机所在服务器的CPU利用率过高     、端口连接不够用等（LR在win环境很容易出现这种问题） 8、压测脚本       最大模拟请求数超过了设置的线程数，导致线程不足 9、业务逻辑       业务逻辑较复杂，导致整个事物线被拉的太长导致 10、系统架构      比如是否有缓存服务，缓存服务器配置，缓存过期等	分布式环境：理论上扩展节点，TPS会呈线性增长，但是发现扩节点后TPS变化不明显，最后发现LR的win环境CPU利用率超过90%
应用服务器CPU利用率过高	1、代码问题 2、服务器资源	1、代码：https://blog.csdn.net/sincool1003/article/details/83088034       1 通过top命令找到占用CPU较高的进程；       2 通过"top -H -p pid"找到java中占用进程过高的线程；       3 根据进程pid使用堆栈信息：jstack -F pid >dump.txt；       4 找到java进程耗费CPU较高的线程id查看堆栈信息。 2、服务器：扩CPU
数据库服务器CPU利用率过高	1、慢sql 2、数据库配置	1、慢sql:       开启mysql慢查询日志，找出慢sql优化 2、数据库配置：       如果其他涉及到sql查询的接口在压测时都没有出现过类似情况，基本排除了数据库服务器 安装配置的问题 3、其他：         1   数据库连接池等参数配置有缺陷，导致连接池不够用，一直在建立新的连接            show processlist 如果有很多空闲连接，说明连接池够用，而且当尝试放大连接池配置 时对CPU没有影              响，则排除连接池问题；　       2  业务代码逻辑可能存在缺陷，导致查询语句消耗过多IO或内存资源           取出该接口的sql,用相同并发数压测，如果CPU利用了下降明显，基本可以排除数据库方面的问题            根据经验猜测可能是一次接口业务中设计到多次数据库操作（如for循环遍历查询），优化后再测试；       3   并发数量高，数据库服务器CPU正常就需要占用这么多。
并发量达到一定程度时报错HystrixRuntimeException
maximum number of expressions in a list is 1000	类似：select content_id from bigscr_scr content where is release=1 and is_delete=0 and content_id in <foreach collection='list" item open="(" close=")" separator="," >#{item.id}  </foreach>	导致这个问题的原因是因为SQL语句中用到了IN字句，结果IN中的元素个数超过了1000导致了这个错误，建议测试时：自己造数据超过一千条，否则这种问题测不出来，后期数据量大了出问题
		内容是参考网上实践整理