分析并优化单次查询很快但是高并发时变慢的接口

目录

摘要

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、总结

摘要

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

1、性能测试

1.1、POSTMAN 50次逐条查询

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

1.2、Jmeter 并发查询

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

50并发

100并发

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

2、数据库慢查询监控

最终还是要回归到数据库上&＃xff0c;对SQL进行分析。

2.1、SQL执行计划分析

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

2.2、单次SQL执行时间

执行时间只有200ms

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

高并发时&＃xff0c;SQL执行时间都在6S左右&＃xff0c;效率比较低

3、Navicat Monitor  监控

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

3.1、总体监控

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

3.2、告警监控

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

当前服务器上的打开连接

每秒全表扫描

最大并发连接数量

InnoDB 写入缓冲区效率

查询缓存命中率

最大允许的数据包

4、优化

简单查看系统用户线程数和 系统支持的最大线程数。&＃xff08;一般都没有问题&＃xff09;

4.1、设置连接数

#如果用户线程的并发数小于64&＃xff0c;可以将这个参数设为0&＃xff0c;如果系统并发很严重&＃xff0c;可以先将这个参数设为128&＃xff0c;或者更大。但是运行一段时间&＃xff0c;看下系统负载&＃xff0c;如果负载过高&＃xff0c;就调低这个参数&＃xff0c;如果负载很低&＃xff0c;也可以调高点。
innodb_thread_concurrency&＃61;128# 如果客户端尝试连接的错误数量超过这个参数设置的值&＃xff0c;则服务器不再接受新的客户端连接。可以通过清空主机的缓存来解除服务器的这种阻止新连接的状态&＃xff0c;通过FLUSH HOSTS或mysqladmin flush-hosts命令来清空缓存。
max_connect_errors &＃61; 30000# 设置客户端的并发连接数量
max_connections &＃61; 2000# 设置客户端的并发连接数量
max_user_connections &＃61; 2000

4.2、缓存配置

# mysql服务缓存以重用的线程数
thread_cache_size &＃61; 120# 为查询结果所分配的缓存
query_cache_size &＃61; 256M#当这个参数为1或ON时&＃xff0c;则MySQL服务器会缓存所有查询结果&＃xff08;除了带有SELECT SQL_NO_CACHE的语句&＃xff09;
query_cache_type &＃61; 1

4.3、最大允许的数据包

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

max_allowed_packet &＃61; 50M

4.4、修改配置

修改mysql以上配置&＃xff0c;并重启数据库

4.5、其他优化

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

优化方式见&＃xff1a;https://blog.csdn.net/weixin_41715077/article/details/100938141

5、缓存优化

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

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

6、程序优化

在zipkin查找&＃xff1a;
http.path&＃61; 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&＃xff0c;

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

7、 并发查询

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

8、性能测试

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

50并发

200并发