记一次SpringBoot应用性能调优过程

这篇具有很好参考价值的文章主要介绍了记一次SpringBoot应用性能调优过程。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

背景

使用SpringBoot、MyBatis-Plus开发一个接口转发的能,将第三方接口注册到平台中,由平台对外提供统一的地址,平台转发时记录接口的转发日志信息。开发完成后使用Jmeter进行性能测试,使用100个线程、持续压测180秒,测试结果如下,每秒仅支持8个并发。
记一次SpringBoot应用性能调优过程

服务器参数

服务器 作用 CPU核数 内存
Jmeter 压测 16 32
MySQL 压测 16 32
接口 模拟第三方接口 8 16
平台 平台 8 16

优化过程

XSS拦截器

首先通过 jstack 命令查看下进程堆栈信息,并在堆栈信息中查询项目的包名,很快找到了几个拦截器的信息,拦截器如下

public class XssEscapeFilter implements Filter {

 public ServletInputStream getInputStream() throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(orgRequest.getInputStream()));
        String line = br.readLine();
        String result = "";
        while (line != null) {
            result += clean(line);
            line = br.readLine();
        }
        return new WrappedServletInputStream(new ByteArrayInputStream(result.getBytes()));
    }
}
...

该拦截器用于对请求的内容先解析成字符串、并对内容进行标签替换,然后在重新放入到流中,先把这个过滤器去除了, 去除后性能测试结果如下,达到了每秒42并发
记一次SpringBoot应用性能调优过程

HTTP连接池

接口转发时需要用到apache httpclient工具,于是找到了http设置连接池的方法,代码如下:

@Bean("closeableHttpClient")
public CloseableHttpClient closeableHttpClient() throws NoSuchAlgorithmException, KeyStoreException, KeyManagementException {
    try {
        //https 配置
        TrustStrategy acceptingTrustStrategy = (X509Certificate[] chain, String authType) -> true;
        SSLContext sslContext = org.apache.http.ssl.SSLContexts.custom()
                .loadTrustMaterial(null, acceptingTrustStrategy)
                .build();

        SSLConnectionSocketFactory csf = new SSLConnectionSocketFactory(sslContext
                , null, null, NoopHostnameVerifier.INSTANCE);

        Registry<ConnectionSocketFactory> registry = RegistryBuilder.<ConnectionSocketFactory>create()
                .register("http", PlainConnectionSocketFactory.getSocketFactory())
                .register("https", csf)
                .build();
        
        PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager(registry);
        // 最大连接数
        connectionManager.setMaxTotal(1000);
        // 路由链接数
        connectionManager.setDefaultMaxPerRoute(100);
        RequestConfig requestConfig = RequestConfig.custom()
                .setSocketTimeout(60000)
                .setConnectTimeout(60000)
                .setConnectionRequestTimeout(10000)
                .build();

        CloseableHttpClient httpClient = HttpClients.custom().setDefaultRequestConfig(requestConfig)
                .setConnectionManager(connectionManager)
                .evictExpiredConnections()
                .evictIdleConnections(300, TimeUnit.SECONDS)
                .build();
        log.info("初始化HttpClient成功,连接池配置:{}", httpConfig);

        Thread httpMonitorThread = new Thread(() -> {
            while (true) {
                final PoolStats poolStats = connectionManager.getTotalStats();
                log.info("等待个数: {} , 执行中个数: {} , 空闲个数: {} , 使用个数: {}/{}", poolStats.getPending(), poolStats.getLeased(), poolStats.getAvailable(), poolStats.getLeased() + poolStats.getAvailable(), poolStats.getMax());
                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    log.error(ExceptionUtils.getStackTrace(e));
                }
            }
        });
        httpMonitorThread.setName("httpMonitor");
        httpMonitorThread.start();
        return httpClient;
    } catch (Exception e) {
        log.error("初始化HttpClient失败", e);
        throw e;
    }
}

通过监控发现HTTP没有出现等待连接情况

数据库连接池

平台使用的是Druid连接池,配置如下:

spring:
  datasource:
    druid:
      # 初始化时建立物理连接的个数,初始化发生在显示调用init方法,或者第一次getConnection时
      initial-size: 100
      # 最大连接池数量
      max-active: 1000
      # 最小连接池数量
      min-idle: 100
      # 获取连接时最大等待时间,单位毫秒;配置了maxWait之后,缺省启用公平锁,并发效率会有所下降,如果需要可以通过配置useUnfairLock属性为true来使用非公平锁。
      max-wait: 60000
      # 是否缓存preparedStatement,也就是PSCache。PSCache对支持游标的数据库性能提升巨大,比如说oracle。在mysql下建议关闭
      pool-prepared-statements: true
      # 要启用PSCache,必须配置大于0,当大于0时,poolPreparedStatements自动触发修改为true。在Druid中,不会存在Oracle下PSCache占用内存过多的问题,可以把这个数值配置大一些,比如说100
      max-pool-prepared-statement-per-connection-size: 20
      # 单位毫秒。有两个含义:一个是Destroy线程会检测连接的间隔时间,如果连接空闲时间大于等于minEvictableIdleTimeMillis则关闭物理连接;另一个是testWhileIdle的判断依据
      time-between-eviction-runs-millis: 60000
      min-evictable-idle-time-millis: 300000
      # 用来检测连接是否有效的sql
      validation-query: SELECT 1
      # 建议配置为true,不影响性能,并且保证安全性。申请连接的时候检测,如果空闲时间大于timeBetweenEvictionRunsMillis,执行validationQuery检测连接是否有效
      test-while-idle: true
      # 申请连接时执行validationQuery检测连接是否有效,做了这个配置会降低性能
      test-on-borrow: false
      # 归还连接时执行validationQuery检测连接是否有效,做了这个配置会降低性能。
      test-on-return: false
      filter:
        stat:
          log-slow-sql: false
          slow-sql-millis: 1000
          merge-sql: false
          enabled: true
        wall:
          config:
            multi-statement-allow: true
      stat-view-servlet:
        enabled: true
        url-pattern: /druid/*
        # 访问SQL监控页面时的登录用户名
        login-username: admin
        # 访问SQL监控页面时的登录密码
        login-password: admin

这里的max-active 不要超过数据库的最大连接个数,通过show variables like '%max_connections%'; 命令可以查询数据库设置的最大连接个数

SQL查询改成缓存查询

每次转发前都需要到数据库进行信息查询,这里把数据库查询改为从JVM缓存查询,去除后性能测试结果如下,达到了每秒 315并发
记一次SpringBoot应用性能调优过程

Logback日志修改为异步打印

使用的logback日志框架,在进行接口转发时会进行日志的打印,在调整日志级别为ERROR时,发现TPS会增加很多,所以猜测和日志打印也有关系,经过查找资料发现,默认日志打印是同步的,可以使用异步打印来提升性能,修改如下

    <!-- 异步日志输出 -->
    <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
        <appender-ref ref="FILE" />
        <!--    解决异步行号不输出问题    -->
        <includeCallerData>true</includeCallerData>
        <!--    日志队列大小,默认 256    -->
        <queueSize>1000</queueSize>
    </appender>

还有一个参数比上面的效果更好,就是在 Appender标签中添加 <immediateFlush>false</immediateFlush> ,当日志的大小达到8k后就会自动写入到日志文件中,带来的问题是没有办法实时查看打印的日志且默认8k的缓冲没有找到修改的办法。

日志异步存储数据库

接口转发时会记录日志方便后续进行问题查找,这里是在响应给客户端前会进行日志存储,是同步存储的,当把这个日志存储代码注释时发现TPS很快就达到了2000,所以猜测是由于存储缓慢导致了系统的TPS上不去,然后就利用SpringBoot的@Aync注解并结合线程池ThreadPoolTaskExecutor进行异步处理,线程池代码如下:

@Slf4j
@Configuration
public class LogSyncThreadPoolConfiguration {

    /**
     * 把springboot中的默认的异步线程线程池给覆盖掉。用ThreadPoolTaskExecutor来进行处理
     **/
    @Bean(name = "logThreadPoolTaskExecutor")
    public ThreadPoolTaskExecutor getThreadPoolTaskExecutor(ApiPlatFormConfig apiPlatFormConfig) {
        ThreadPoolConfig threadPool = apiPlatFormConfig.getThreadPool();
        ThreadPoolTaskExecutor threadPoolTaskExecutor = new ThreadPoolTaskExecutor();
        threadPoolTaskExecutor.setCorePoolSize(threadPool.getCorePoolSize());
        threadPoolTaskExecutor.setMaxPoolSize(threadPool.getMaxPoolSize());
        threadPoolTaskExecutor.setQueueCapacity(threadPool.getQueueCapacity());
        threadPoolTaskExecutor.setKeepAliveSeconds(threadPool.getKeepAliveSeconds());
        threadPoolTaskExecutor.setThreadNamePrefix(threadPool.getThreadNamePrefix());
        threadPoolTaskExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy());
        threadPoolTaskExecutor.initialize();
        threadPoolTaskExecutor.setAllowCoreThreadTimeOut(true);
        if (threadPool.getMonitor()) {
            log.info("开启线程池监控");
            Thread threadPoolMonitor = new Thread(() -> {
                while (true) {
                    int poolSize = threadPoolTaskExecutor.getPoolSize();
                    int activeCount = threadPoolTaskExecutor.getActiveCount();
                    int queueSize = threadPoolTaskExecutor.getThreadPoolExecutor().getQueue().size();
                    long completedTaskCount = threadPoolTaskExecutor.getThreadPoolExecutor().getCompletedTaskCount();
                    log.info("【{}】线程池信息, 最大线程数: {}, 核心线程数: {}, 当前线程池大小: {}, 当前活动线程数: {}, 当前队列长度: {}/{}, 已完成任务个数: {}", threadPool.getThreadNamePrefix(), threadPool.getMaxPoolSize(), threadPool.getCorePoolSize(), poolSize, activeCount, queueSize, threadPool.getQueueCapacity(), completedTaskCount);
                    try {
                        TimeUnit.SECONDS.sleep(threadPool.getMonitorIntervalSeconds());
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                }
            });
            threadPoolMonitor.setName("监控线程");
            threadPoolMonitor.start();
        }
        return threadPoolTaskExecutor;
    }
}

无论上述的线程池大小怎么调整,发现TPS的变化幅度不大,于是怀疑是不是数据库的性能不行,并对数据库进行了性能测试

数据库性能测试

将日志的插入语句拿出来当做测试案例,同样的使用 100个线程压测180秒,数据库插入性能如下,数据库支持每秒1300并发,所以程序还是有优化空间的
记一次SpringBoot应用性能调优过程

使用队列+批量提交

使用线程池虽然是异步了,但是始终是一条一条的往数据库中插入的,如果改为批量插入的话,应该会提高性能,所以将日志存储的地方修改为存储到队列中,这里使用LinkedBlockingQueue队列,并启动一个线程一直消费该队列,当消费的数量达到批量提交的个数时进行数据库插入,启动一个线程监控队列的消费情况,代码案例如下:

Thread logQueueMonitorThread = new Thread(() -> {
            long lastCount = 0;
            while (true) {
                long nowCount = count.get();
                log.info("队列当前积压数量:{} , 新增处理数: {} , SQL批量插入大小: {} ,  总处理数: {} , 总异常数: {}", QUEUE.size(), nowCount - lastCount, logQueueConfig.getSqlBatchSize(), nowCount, errorCounter.get());
                lastCount = nowCount;
                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    log.error(ExceptionUtils.getStackTrace(e));
                }
            }
        });
        logQueueMonitorThread.setName("logQueueMonitor");
        logQueueMonitorThread.start();

经过测试发现TPS可以达到了1300左右,而且队列的积压个数没有明显的增长,一直小于批量提交的个数。
记一次SpringBoot应用性能调优过程

其他说明

在上面的机器中测试发现一个简单的SpringBoot应用,里面写一个测试接口直接返回固定字符串,性能接近20000TPS每秒,而平台也按照上述操作测试接口发现性能在3000TPS左右,性能损耗非常大,不知道是不是因为用了Shiro导致,后面会再进行单独的测试验证。文章来源地址https://www.toymoban.com/news/detail-439021.html

到了这里,关于记一次SpringBoot应用性能调优过程的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 记一次Flink遇到性能瓶颈

    这周的主要时间花在Flink上面,做了一个简单的从文本文件中读取数据,然后存入数据库的例子,能够正常的实现功能,但是遇到个问题,我有四台机器,自己搭建了一个standalone的集群,不论我把并行度设置多少,跑起来的耗时都非常接近,实在是百思不得其解。机器多似乎

    2023年04月15日
    浏览(78)
  • 记一次翻页性能优化

       由于是公司项目,所以不方便给出代码或者视频,只能列一些自己画的流程图。    大致情况如上,前端有7个显示区。在对其进行滚动翻页的时候,存在以下问题:    通过分析代码,调查log发现,翻页切换平均耗时在600ms。其主要的业务逻辑如下: 主要问题有

    2024年02月05日
    浏览(48)
  • 记一次Kafka重复消费解决过程

            起因:车联网项目开发,车辆发生故障需要给三个系统推送消息,故障上报较为频繁,所以为了不阻塞主流程,采用了使用kafka。消费方负责推送并保存推送记录,但在一次压测中发现,实际只发生了10次故障,但是推送记录却有30多条。         问题排查,发现

    2024年02月13日
    浏览(60)
  • 记一次linux复制病毒处理过程

    某天我的阿里云突然发信息告诉我服务器有自变异木马,我用远程工具连接服务器异常卡顿甚至掉线,reboot也不好使.用阿里云的网页控制台会好些,但还是卡,我又用阿里云控制台重启服务器,重启之后发现服务器完全连不上了,ping也ping不通了,我问了客服说可以用救援连接试试,果

    2024年01月24日
    浏览(64)
  • 记一次 stackoverflowerror 线上排查过程

         xxx 日,突然收到线上日志频繁告警 classCastException .从字面上的报警来看,仅仅是类型转换异常,查看细则发现其实是 stackOverFlowError .很多同学面试的时候总会被问到有没有遇到过线上 stackOverFlowError ?有么有遇到栈溢出?具体栈溢出怎么来解决?今天他来了,他带着问题走

    2024年01月23日
    浏览(44)
  • 记一次后台开发面试拷打过程

    开头简单的自我介绍,面试官和我聊了聊天缓解个人紧张状况,然后就让开屏幕共享开视频做题目,做完以后,问了一些问题,就让等通知了,估计是凉了,不过这里且把当时做的笔试题目复盘一下吧!题目是ai做的题解,唉,AI都比我强,比我面试的时候解释的强多了,未来

    2024年02月08日
    浏览(43)
  • 记一次线上BUG排查过程

    1. 线上遇到一个非常奇怪的bug,为一个用户分配业务线类型后,该用户登录时,提示502,但其它的用户登录完全是正常的 2. 问题现象 3. 排查思路 先去看线上日志,看是否有error,但日志里边这个接口200正常返回 本地debug,也复现一样问题,在分配角色类型超过22个总数时就报

    2024年02月09日
    浏览(53)
  • 记一次docker服务启动失败解决过程

    环境:centos 7.6 报错:start request repeated too quickly for docker.service 由于服务器修复了内核漏洞,需要重启,没想到重启后,docker启动失败了 查看状态 如下图 里面有一行提示: 提示要 journalctl -x 这个命令查看详细问题,其实用这个命令无法定位到具体问题的,于是使用了另外一

    2024年01月18日
    浏览(78)
  • 记一次批量更新mysql数据过程

    一、前言 需求背景:mysql数据库中有一个表的数据(600多万)有一个字段的内容需要解密再通过另外一种加密方式进行加密再回存。通过java程序计算完成更新。 二、方案一 一条条计算更新。这里是将手机号解密,在通过另外一种方式回存。 算法步骤: 1、查询需要解密的数

    2024年02月10日
    浏览(35)
  • 记一次 Oracle 下的 SQL 优化过程

    事情是这样的,UAT 环境的测试小伙伴向我扔来一个小 bug,说是一个放大镜的查询很慢,转几分钟才出数据,我立马上开发环境试了一下,很快啊我说😏,放大镜的数据立马就出来了,然后我登录 UAT 环境一看,诶是有些慢😕 ,于是开始了我的排查之旅... 首先我立马拿到了

    2024年02月05日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包