记一次接口优化操作

*[En]*

**

*[En]*

**

数达到约3 万。而且这只是部分用户在进行使用,还没有大规模地放开,服务器已经

*[En]*

**

日志信息,排查问题。通过命令 grep”接口请求的URL” 日志文件名,查看多台服务

器上面打印的日志信息,发现确实有多台服务器上打印的接口耗时都超过5S 以上。

*[En]*

**

接口的好坏?其中一个指标就是处理请求的能力,可以通过jmeter 来做接口的性能测试。

*[En]*

**

*[En]*

**

*[En]*

**

首先需要定义一个拦截器:

@Slf4j

public class InterfaceInterceptor implements HandlerInterceptor {

@Override

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

request.setAttribute(“REQUEST_START_TIME”, String.valueOf(System.currentTimeMillis()));

return true;

}

@Override

public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {

String requestURI = request.getRequestURI();

String requestStartTime = (String)request.getAttribute(“REQUEST_START_TIME”);

log.info(“接口{}请求耗时: {} ms”, requestURI, System.currentTimeMillis() – Long.parseLong(requestStartTime));

}

}

重写两个方法,一个方法是在处理请求前调用的preHandle方法,处理逻辑很简单,设置一个固定的变量值,

具体的值设置为当前的时间戳,将其放在请求对象中。接口请求处理完成之后,调用afterCompletion方法,

将之前存入的值取出来,转换为Long 类型,然后用当前时间时间戳减去最开始请求的时间戳,就可以计算出单个接口处理的耗时。

接下来写一个简单的测试方法,如下

@Slf4j

@RestController

@RequestMapping(“/happy/yilang”)

public class TestControlelr {

@GetMapping(“/interface”)

@LcloudThreadLimiter(maxThread=”max_thread”, waitTime=”wait_time”)

public String interfaceTest(){

return “接口耗时统计”;

}

}

最后将拦截器添加到拦截器配置类中,即是注册拦截器,拦截的指定的路径为/happy/**,可以

按需要进行灵活的配置,如下

@Configuration

public class WebMvcConfig extends WebMvcConfigurerAdapter {

/**

  • Function: addInterceptors

  • Author : kaye0110,

  • Version : 1.0

  • Description : 注册拦截器

  • Param and Description :

  • @param registry

*/

@Override

public void addInterceptors(InterceptorRegistry registry) {

registry.addInterceptor(InterfaceInterceptor()).addPathPatterns(“/happy/**”);

super.addInterceptors(registry);

}

@Bean

public InterfaceInterceptor InterfaceInterceptor(){

return new InterfaceInterceptor();

}

}

启动项目,测试结果如下

记一次接口优化操作

拿到每一次接口请求的耗时数据,对于性能要求是一个重要的参考指标。每个公司的要求都不一样,有的可能要求1s 内返回,

有的可能要求500ms 内返回,有的可能要求20ms 内返回。根据公司自己的要求,然后来对比接口的耗时,就可以判断出这个

接口的性能如何,是否需要优化。

自己在排查日志的过程中发现,这个接口就是一个简单的接口,没有做比较复杂的计算操作,就是根据主键ID 查询一条数据

信息,为什么会导致这么慢呢?怎么进行优化呢?之后经过仔细分析,发现在请求高峰期的时候,数据库的CPU 达到90%多,

因为数据库的性能急剧下降。负责人经过查看数据库服务器的相关信息,普通开发人员没权限看,还发现MQ 在快速的大量的

向数据库中写数据, 还有定时任务也在频繁的向数据库写数据,所以导致数据库的性能解决下降。由于起了多台服务器,定时

任务的处理就更加地频繁,如果每间隔两分钟处理一次定时任务,5 台服务器两分钟就处理10 次。因此就找到对应的解决方案:

.1.扩容数据库;.2.这个接口实时查询数据库修改为从缓存中取数据;.3.增加定时任务的处理时间间隔;4.降低MQ 消息消费的流量。

*[En]*

**

最终很好地解决了这个接口的性能问题。

如果有其他更好建议的小伙伴,欢迎留言讨论。

Original: https://www.cnblogs.com/yilangcode/p/16942979.html
Author: yilangcode
Title: 记一次接口优化操作

原创文章受到原创版权保护。转载请注明出处:https://www.johngo689.com/222811/

转载文章受原作者版权保护。转载请注明原作者出处!

(0)

大家都在看

最近整理资源【免费获取】:   👉 程序员最新必读书单  | 👏 互联网各方向面试题下载 | ✌️计算机核心资源汇总