目录

摘要

1、性能测试

1.1、POSTMAN 50次逐条查询

1.2、Jmeter 50 并发查询

1.3、Jmeter 100 并发查询

2、数据库慢查询监控

2.1、SQL执行计划分析

2.2、单次SQL执行时间

2.3、并发情况下SQL执行时间

3、Navicat Monitor  监控

3.1、总体监控

3.2、告警监控

4、优化

4.1、设置连接数

4.2、缓存配置

4.3、最大允许的数据包

4.4、修改配置

4.5、其他优化

5、缓存优化

6、程序优化

7 并发查询

8、性能测试

6、总结

系统中出现了很多，单次查询很快，但是并发量一高就变慢的接口。下面根据具体情况，进行分析并解决相关性能问题。优化的点主要就是 数据库、缓存、接口逻辑、并发设计等。

逐条执行的时候，响应时间基本都是一致的，且比较快。

在并发测试的时候，数据库并发连接数增加以后，查询的响应时间，明显增加很多。

50并发

Samples

吞吐量Throughput

最小响应时间

最大响应时间

平均响应时间

错误率

50

3.3/sec

5188ms

14379ms

10504ms

0％

100并发

Samples

吞吐量Throughput

最小响应时间

最大响应时间

平均响应时间

错误率

100

3.3/sec

6421ms

29513ms

18282ms

0％

zipkin调用链拿到调用信息，最好能拿到接口的调用详情，可辅助分析性能问题

最终还是要回归到数据库上，对SQL进行分析。

已经使用了索引，说明SQL本身的效率应该是可以的

执行时间只有200ms

高并发时，SQL执行时间都在6S左右，效率比较低

借助监控工具可以有效的分析数据库的性能瓶颈，也可通过其他的监控工具，比如monyog,Innotop等。通过上面的分析，可以断定部分问题应该还是出在数据库上。

首先分别在5:48,5.50,5.54 做了三次压测。然后截取监控图片如下，应该不是内存和CPU资源不足的问题，再看数据库的总连接数，明显小于已记录的最大并发连接数量。

重点分析严重的告警，其中两个跟数据库的连接数有关。

当前服务器上的打开连接

每秒全表扫描

最大并发连接数量

InnoDB 写入缓冲区效率

查询缓存命中率

最大允许的数据包

简单查看系统用户线程数和 系统支持的最大线程数。（一般都没有问题）

考虑下网络带宽，有的企业内网可能就是100M，所以设置成50M，一般就足够了。

修改mysql以上配置，并重启数据库

对于全表扫描的情况，说明还有很多额外的SQL 没有使用索引。要逐一优化。主要是给表都加上合适的索引，同时还要分析表模式设计是不是有问题，必要时可以添加一些冗余字段（主要是枚举值的字段或者不会修改的字段），尽量避免多表关联的情况。

优化方式见：https://blog.csdn.net/weixin_41715077/article/details/100938141

数据库的问题解决了，其他问题应该还是出在应用程序的设计上。最好借助监控工具分析下，可以借助zipkin或者skywalking等分布式调用链监控工具分析响应最慢的一些接口。

在zipkin查找： http.path=/plan/api/alarm/history   很多其他接口需要这个三个接口的提供基础数据，于是将查询结果全部放到redis中。 /iir/manager/device/list-all /visible/api/visible-equipment/list-all /iir/manager/device-handle/all/list

在zipkin查找： http.path= device/api/monitor/device-list   发现For 循环频繁调用设备服务的接口。 http.method GET http.path /device/api/device-monitor/type mvc.controller.class DeviceMonitorServiceImpl mvc.controller.method getMonitorDeviceType Client Address 10.0.10.210:46850，

将for循环中查询接口 修改成批量查询接口，在for循环外层调用一次，然后在内层组织数据。

优化过程发现，一些代码在for循环中逐条调用图片接口拉取图片，而这个图片接口是通过ceph 的网关拉取图片的，没办法像数据库一样改成批量查询，这里 Cellection.parallelStream()并发拉取图片，提高效率。

找其中一个接口测试下调优后的性能。

50并发

200并发