登陆时间的优化

把帆帆喂饱
• 阅读 1033

登陆时间的优化

登陆时间的优化

这是一个登陆的请求,在项目启动后首次调用,耗时近800ms,而第二次调用改接口时则只花费了29ms,性能有较大的提升空间。

下面针对此问题进行一系列的优化。

耗时排查

登陆时间的优化

项目启动后清空日志,然后调用接口,发现会创建一个dispatcherServlet,耗时4ms,又根据日志实际打印的时间发现,实际耗时近200ms

登陆时间的优化

数据库初始化以及链接耗时近400ms,存在很大优化空间 。

登陆时间的优化

业务执行第一次耗时也非常久。

优化

1、启动时自动执行Initializing

在spring boot load-on-startup默认值是-1,项目启动时,默认不会初始化DispatcherServlet,也就是不会调用Servlet接口的init()方法

在yml配置文件中进行如下配置,即可指定启动时初始化:

spring:
    servlet:
    load-on-startup: 1  # 启动的时候初始化DispatcherServlet

2、数据库优化

hikari:
      minimum-idle: 10 # 池中维护的最小空闲连接数
      connection-test-query: SELECT 1

登陆时间的优化

在如上两步操作后,发现性能得到了部分优化,但还是达不到理想的效果

经过检查,在如上配置后数据库并没有初始化。

3、项目启动优化

创建类InitRunner 继承ApplicationRunner

ApplicationRunner是一个接口,常用于项目启动后,(也就是ApringApplication.run()执行结束),立马执行某些逻辑。

可用于项目的准备工作,比如加载配置文件,加载执行流,定时任务等等。

@Component
@Slf4j
public class InitRunner implements ApplicationRunner {

  @Resource
  private IUserService userService;

  @Override
  public void run(ApplicationArguments args) throws Exception {
    ThreadUtil.execAsync(() -> {
      try {
        userService.getById(1); // 数据库探测,帮我在项目启动的时候查询一次数据库,防止数据库的懒加载
        log.info("启动项目web请求查询成功");   // 发送一次异步的web请求,来初始化 tomcat连接
        HttpUtil.get("http://localhost:9090/"); 
        log.info("启动项目tomcat连接查询成功");   // 发送一次异步的web请求,来初始化 tomcat连接
      } catch (Exception e) {
        log.warn("启动优化失败", e);
      }
    });
  }
} 

登陆时间的优化

登陆时间的优化

再次测试发现,前端网络请求共耗时418ms,后端方法执行则耗费了256ms,那么 中间还有150ms发生了什么呢?将日志打印级别修改为debug

登陆时间的优化

登陆时间的优化

查看日志发现是tomcat占用了较多时间

于是在项目初始化的时候就调用http请求,以完成tomcat初始化

@Component
@Slf4j
public class InitRunner implements ApplicationRunner {

  @Resource
  private IUserService userService;

  @Override
  public void run(ApplicationArguments args) throws Exception {
    ThreadUtil.execAsync(() -> {
      try {
        userService.getById(1); // 数据库探测,帮我在项目启动的时候查询一次数据库,防止数据库的懒加载
        log.info("启动项目web请求查询成功");   // 发送一次异步的web请求,来初始化 tomcat连接
        HttpUtil.get("http://localhost:9090/");
        log.info("启动项目tomcat连接查询成功");   // 发送一次异步的web请求,来初始化 tomcat连接
      } catch (Exception e) {
        log.warn("启动优化失败", e);
      }
    });
  }

}

登陆时间的优化

测试后,优化完成。

点赞
收藏
评论区
推荐文章
Stella981 Stella981
3年前
Cmder启动速度优化
为加快cmder启动,我们可以做一些简单优化,减少环境变量检测和批处理调用操作优化前启动时间:1.69秒优化后启动时间:0.53秒1\.将cmder下批处理中lib\_console输出禁用    
Wesley13 Wesley13
3年前
RTSP拉流协议视频平台多点认证造成潜在威胁?如何破解?
上一篇我们讲了TSINGSEE青犀视频平台EasyNVR内登陆鉴权的优化,通过优化登陆鉴权,我们可以抵御很多分发用户的攻击。在该问题优化完成后,我们模拟不法分子的攻击对EasyNVR的安全性进行了测试,EasyNVR已经达到了一个安全性很高的级别。!203.png(https://imgblog.csdnimg.cn/img_convert/937
Stella981 Stella981
3年前
Shiro 放行Swagger
一、前言在使用SpringBootShiroMybatisSwagger开发后台权限管理系统的时候,由于SpringBoot采用了Shiro框架,同时API接口文档使用的Swagger,遇到一个问题,在SpringBoot集成Shiro后,访问Swagger接口需要登陆才可以,由于在项目成型之前需要做接口测试,所以这里记录下如何在Shi
Stella981 Stella981
3年前
Spring AOP 切面编程记录日志和接口执行时间
最近客户现在提出系统访问非常慢,需要优化提升访问速度,在排查了nginx、tomcat内存和服务器负载之后,判断是数据库查询速度慢,进一步排查发现是因为部分视图和表查询特别慢导致了整个系统的响应时间特别长。知道了问题之后,就需要对查询比较慢的接口进行优化,但哪些接口需要优化、哪些不需要呢?只能通过日志里的执行时间来判断,那么如何才能知道每一个接口的执行时间呢
Easter79 Easter79
3年前
SpringCloud项目,接口调用返回http 500
今天上班的时候,自己正在参与的SpringCloud项目出现了问题,原本上周五还正常的项目突然所有接口调用都是返回http500的错误。项目的状态是在Eureka上可以看到对应微服务是在线状态,然后在Swagger里面测试接口,发现接口间歇性调用失败,也就是题目中的http500的错误,如下图。至于是间歇性的原因在于这个服务在线上部署了一个,然后我
提供方耗时正常,调用方毛刺频频
作者:京东零售王森一现象调用方AJSF提供方B大多数情况下,调用方耗时和提供方耗时基本没有差别个别情况下,调用方耗时远高于提供方耗时,大概5分钟20次1.调用方A耗时如下图2.提供方B耗时如下图3.调用方监控添加在调用JSF接口前后加的监控,没有其他任何
接口优化的常见方案实战总结
针对老项目,去年做了许多降本增效的事情,其中发现最多的就是接口耗时过长的问题,就集中搞了一次接口性能优化。本文将给小伙伴们分享一下接口优化的通用方案。
G1垃圾回收参数调优及MySQL虚引用造成GC时间过长分析 | 京东云技术团队
我方有一应用,偶尔会出现GC时间过长(间隔约4小时),导致性能波动的问题(接口最长需要耗时3秒以上)。经排查为G1垃圾回收器参数配置不当叠加MySQL链接超过闲置时间回收,产生大量的虚引用,导致G1在执行老年代混合GC,标记阶段耗时过长导致。以下为对此问题的分析及问题总结。
京东云开发者 京东云开发者
6个月前
性能优化之路总结
针对老项目,去年做了许多降本增效的事情,其中发现最多的就是接口耗时过长的问题,就集中搞了一次接口性能优化。本文将给小伙伴们分享一下接口优化的通用方案。一、接口优化方案总结1.批处理批量思想:批量操作数据库,这个很好理解,我们在循环插入场景的接口中,可以在批
提供方耗时正常,调用方毛刺频频
作者:京东零售王森一现象调用方AJSF提供方B大多数情况下,调用方耗时和提供方耗时基本没有差别个别情况下,调用方耗时远高于提供方耗时,大概5分钟20次1.调用方A耗时如下图2.提供方B耗时如下图3.调用方监控添加在调用JSF接口前后加的监控,没有其他任何
把帆帆喂饱
把帆帆喂饱
Lv1
自卑溢出来就变成了安静和温柔。
文章
7
粉丝
6
获赞
6