一次接口的性能优化之旅

一、引言

在项目开发过程中,我们经常会遇到接口响应慢的问题。这不仅影响了用户体验,还可能降低了系统的吞吐量。为了提高接口性能,我们需要对整个系统进行全面的优化,包括代码层面、数据库、缓存、异步处理等方面。本文将分享一个接口性能优化之旅,希望能帮助大家掌握Pfinder使用、JSF异步调用等优化技巧,提升接口性能和定位问题的能力。

二、现状诊断

•UMP诊断:

◦Max:10s

◦T99:1000ms

◦经常可用率下降









•Pfinder诊断:

◦问题1:循环调用RPC 120次=1441ms

◦问题2:查询DB 286ms

◦问题3:未知操作 2000ms+





三、问题定位以及性能优化

如何解决Pfinder显示耗时不全问题:-> 手动完善全程跟踪上报

1.集成Pfinder SDK:

<!-- 引用 PFinder SDK--> <dependency> <groupId>com.jd.pfinder</groupId> <artifactId>pfinder-profiler-sdk</artifactId> <version>1.2.2-FINAL</version> </dependency>

1.使用注解:@PFTracing





1.上报效果





1.定位问题和进行代码分析





这段代码的目的是从一个名为waveInfos的字符串列表中,筛选出已经包含在另一个名为sendDPackageCodes的字符串列表中的元素,并将这些重复的元素放入一个新的列表repeatResult中。然后,它从waveInfos中排除这些重复的元素,将剩余的元素放入另一个新的列表showPackages中。这两个列表最终被用于前端显示或进一步处理。简而言之,这段代码的作用是去重并筛选出尚未处理的数据。



通过现象查看此处代码耗时占总耗时进一半左右,因此判断集合数据非常多,导致数据计算耗时较长。通过日志打印发现:waveInfos=3000+,sendDPackageCodes=7000+,因此可以看出两个集合因为数据过大导致耗时较长。





代码优化:使用Set进行处理









优化效果:2000ms -> 6ms

如何解决RPC批量调用问题 -> 使用JSF异步调用

同步异步方案比较

优劣势异步调用同步调用
优势提高系统的并发性能简单直观
提高系统的响应速度错误处理方便
节约资源
劣势复杂性阻塞线程
可读性差响应速度慢

JSF异步调用使用

第一步:如果存在同步bean,为了不影响同步bean可以注入新的异步bean。需要

注意:jsf 这边相同接口 别名 最多支持3个

// 同步bean @Autowired private XxxxxApi xxxxApi; // 异步实现bean,(jsf 这边相同接口 别名 最多支持3个) @Autowired private XxxxxApi xxxxAsyncApi; <!-- 【异步】路由查询班次单号明细 --> <jsf:consumer id="xxx" interface="xxx" protocol="jsf" alias="xx" timeout="xxx" retries="0" check="false"> <jsf:method name="方法名称" async="true"/> </jsf:consumer>

第二步:使用RpcContext调用,返回CompletableFuture对象

// Rpc代理类 需要返回CompletableFuture 对象 public CompletableFuture<CommonDto<PageDto>> queryWaybillDetailByBusinessIdByAsync() { // 发起方法请求 return RpcContext.getContext().asyncCall(() -> xxxxAsyncApi.method());; }

第三步:调用处任意地方,获取future返回结果,需要指定超时时间

public <T> T getResultDefaultTimeOut(CompletableFuture<T> future) { try { return future.get(10, TimeUnit.SECONDS); } catch (InterruptedException | ExecutionException | TimeoutException e) { throw new RuntimeException(e); } }

优化效果:1400ms -> 200ms

五、最终效果和未解决问题

优化前优化后

问题优化前优化后方案
总耗时3800ms500ms
rpc循环调用1400ms200msJSF异步调用(N次耗时变一次最大耗时)
数据笛卡尔积处理2000ms6mslist包含操作变set包含操作
数据库操作100ms100ms数据库批量查询,此期不处理
未知操作150ms150ms非业务代码,怀疑是sql查询后结果处理,目前无法跟踪和处理,此期不处理

六、总结

接口性能优化是一个涉及多个方面的过程,需要从代码层面、数据库、缓存、异步处理等多个维度进行优化。在这个过程中,我们需要不断诊断瓶颈、尝试优化手段,并结合实际情况进行调整。希望通过本文的分享,大家能掌握接口性能优化的方法和技巧,提高接口性能,提升用户体验。

点赞
收藏

评论区

加载中...

相关推荐

常用性能调优策略及在风控场景下应用

引言性能调优也是有迹可寻的,本文梳理了在实际开发过程中沉淀的通用性能优化策略,并且结合风控系统服务内使用场景,帮助读者理解性能调优相关可行策略,从而建立性能优化SOP概念,以后出现问题即可参照优化流程改造即可。<!

springboot2.x配置druid sql监控

  后端接口响应慢,通常我们就需要优化代码和sql,如果项目中使用druid连接池,那么我们可以利用其提供的sql监控功能,来帮助我们快速定位慢sql已经sql执行次数等问题,springboot2之后,durid监控配置变的更简单了,不需要额外的代码,只需要添加配置即可。整个项目配置如下:  依赖<dependency

Spring AOP 切面编程记录日志和接口执行时间

最近客户现在提出系统访问非常慢,需要优化提升访问速度,在排查了nginx、tomcat内存和服务器负载之后,判断是数据库查询速度慢,进一步排查发现是因为部分视图和表查询特别慢导致了整个系统的响应时间特别长。知道了问题之后,就需要对查询比较慢的接口进行优化,但哪些接口需要优化、哪些不需要呢?只能通过日志里的执行时间来判断,那么如何才能知道每一个接口的执行时间呢

Redis企业级应用

   我们在做项目的时候经常会遇到很多性能的问题,也成为整个系统优化最疼痛的问题,主要还是因为在用户量大的时候或者就是说高并发访问的时候,我们系统的数据库会有一个限制。当然也可以通过对数据库的优化对系统进行优化,(最常见的数据库优化手段无非就是建索引,explain分析慢sql,以及sql语句的优化或者分库分表等一系列的策略,当然后面我会专门写一篇文章专

《优化接口设计的思路》系列:第九篇—用好缓存,让你的接口速度飞起来

前面的文章都是写接口如何设计、接口怎么验权以及一些接口常用的组件,这篇写点接口性能相关的。接口性能优化有很多途径,比如表建索引、SQL优化、加缓存、重构代码等等,本篇文章主要讲一下我是怎么在项目中使用缓存来提高接口响应速度的。

融云IM干货丨 在优化IM服务API接口时,有哪些常见的性能瓶颈?

在优化IM服务API接口时,常见的性能瓶颈主要包括以下几个方面:数据库瓶颈:SQL查询过慢:数据库中的SQL查询没有经过优化,查询复杂,索引设计不合理,或者需要对大量数据进行扫描,导致数据库响应变慢。数据库连接池耗尽:在高并发请求场景下,数据库连接池中的连