Springboot并发调优之大事务和长连接

1、背景

在当前这个快速开发的环境下，很多时候我们的应用都是测试好好的，正式环境并发一高就一团糟。不了解并发相关参数，看不懂压测报告，是很多程序猿的基本状态。本文重点分享长事务以及长连接导致的并发排查和优化思路和示例。

长事务会导致长连接，长连接未必是因为长事务，因果关系先搞清楚。

主要相关技术：

SpringBoot： 2.5.12
mybatis-spring-boot-starter： 2.1.2
druid-spring-boot-starter： 1.2.9
mysql-connector-java： 8.0+
tomcat： 9.0.54

2、主要参数释义：

2.1 tomcat主要并发参数释义

server:
  port: 8080
  compression:
    enabled: true
  tomcat:
    accept-count: 511
    max-connections: 8192
    threads:
      max: 200
    basedir: /u01/app/base/logs/tomcat
    connection-timeout: 60000
    keep-alive-timeout: 60000

threads.max：表示服务器最大有多少个线程处理请求，默认200，实际上这个参数超过服务器核心数太多反而会降低服务器cpu处理速度，对于计算密集型和IO密集型应分开考虑设置该参数。

max-connections：表示服务器与客户端可以建立多少个连接数，即持有的连接数。tomcat缺省是8192个连接数，cpu未必有时间给你处理，但是可以保持连接。这个参数是客户感知型参数。

accept-count: 与服务器内核相关，是客户端传入给服务器内核，请求的backlog值，该值与服务器内核参数net.core.somaxconn取小后的值为最终起效的TCP内核全队列值。它表示在max-connections值达到预设的值后，服务器内核还能建立的连接数，这个连接保存在内核，还未被上层应用（tomcat）取走。该值在tomcat中默认是100，在Centos7.x版本中内核net.core.somaxconn是128。如果超过max-connections和accept-count总和，新的连接会被拒绝，即直接拒绝服务（直接返回connection refused）。

查看CentOS的net.core.somaxconn参数：sysctl -a|grep net.core.somaxconn

2.2 数据库连接池参数

  datasource:
    type: com.alibaba.druid.pool.DruidDataSource
    druid:     
      driver-class-name: com.mysql.cj.jdbc.Driver
      #连接池属性
      initial-size: 5
      max-active: 140
      min-idle: 10
      # 配置获取连接等待超时的时间
      max-wait: 30000     
      connect-properties.slowSqlMillis: 2000

max-active: 数据库连接池数据连接最大数量，即连接池物理打开数据库的最大数量。这个参数一般开发人员都会错误的设置，首先这个值不是越大越好，最起码它得小于数据库本身配置的最大连接数，如果超过后再向数据库发起连接，就会在数据库层面抛出类似"too many connection"的错误。mysql数据库默认最大连接数为151。一般配置数据库连接池应用组件的时候，不要超过这个数，并且需要留一部分连接数给维护人员使用。

2.3 数据库连接数

上文2.2已经提到数据库连接数，它决定了数据库支持的最大并发数。

查看mysql的最大连接数：

show variables like '%max_connections%';

查看mysql目前的连接数：

show global status like 'Max_used_connections';

如果你的应用配置连接数超过数据库预设的最大数，并且客户端不断并发的发起数据库连接，连接池数量就会不断创建与数据库的物理连接，如果该连接是各种原因导致的数据库长连接（例如：长事务），那么一旦超过数据库的最大值，应用就会报连接数太多的错误。

3、测试程序

两个对外暴露的url：

5000毫秒的长连接操作
100毫秒的短连接操作

Controller:

    @GetMapping("/slowGetAll")
    public Result<Object> slowGetAll(){
        return Result.ok(testUserService.queryAll());
    }

    @GetMapping("/fastGetAll")
    public Result<Object> fastGetAll(){
        return Result.ok(testUserService.fastGetAll());
    }

service: 向数据库里插入两个用户，并查询最后一个用户的信息，在两次insert操作中间加入一个耗时操作。

    @Transactional(rollbackFor = Exception.class)
    @Override
    public List<TestUser> fastGetAll() {
        TestUser user1 = getTestUser("李四", "jerry");
        this.testUserDao.insert(user1);
        slowMethod(customProperties.getFastMillis());

        TestUser user2 = getTestUser("张三", "tom");
        this.testUserDao.insert(user2);

        return this.testUserDao.queryByBlurry(user2);
    }


    @Transactional(rollbackFor = Exception.class)
    @Override
    public List<TestUser> queryAll() {
        TestUser user1 = getTestUser("王五", "jack");
        this.testUserDao.insert(user1);
        slowMethod(customProperties.getSlowMillis());

        TestUser user2 = getTestUser("赵柳", "amy");
        this.testUserDao.insert(user2);

        return this.testUserDao.queryByBlurry(user2);
    }

    private void slowMethod(int milliseconds){
        try {
            int i = globalCount.incrementAndGet();
            System.out.println("slowMethod start -->"+i);
            Thread.sleep(milliseconds);
            System.out.println("slowMethod end -->"+i);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

注意，这里的长连接使用使用Thread.sleep实现，不是真正的数据库长事务。

4、jmeter测试

开启400线程，测试10轮，分两组：

快速处理的短连接4000次。
慢速处理的长连接4000次。

4.1、快速组

druid连接池主要结果分析：

指标	值	解释
事务时间分布	0,0,3735,265,0,0,0	事务运行时间分布，分布区间为[0-1 ms, 1-10 ms, 10-100 ms, 100-1 s, 1-10 s, 10-100 s, >100 s]
连接持有时间分布	0,0,0,3583,417,0,0,0	连接持有时间分布，分布区间为[0-1 ms, 1-10 ms, 10-100 ms, 100ms-1s, 1-10 s, 10-100 s, 100-1000 s, >1000 s]

在JMeter中的吞吐量为：305.4/second

4.2、慢速组

druid连接池主要结果分析：

指标	值	解释
事务时间分布	0,0,3599,401,0,0,0	事务运行时间分布，分布区间为[0-1 ms, 1-10 ms, 10-100 ms, 100-1 s, 1-10 s, 10-100 s, >100 s]
连接持有时间分布	0,0,0,0,4000,0,0,0	连接持有时间分布，分布区间为[0-1 ms, 1-10 ms, 10-100 ms, 100ms-1s, 1-10 s, 10-100 s, 100-1000 s, >1000 s]

在JMeter中的吞吐量为：26.3/second

4.3、对照分析

事务时间分布：非数据库操作的耗时对事务时间分布是没有影响的，快速组和慢速组分布区间基本相同。

连接持有时间分布：快速组大约90%的时间分布在100ms-1s，慢速组100%分布在1-10 s，符合预期的设置。

吞吐量：快速组比慢速组快了接近10倍。

小小结论：在慢速组中，虽然事务的分别时间较短，但是发起该事务的连接一直没有被释放，导致并发能力断崖式下降。

5、问题与优化

5.1、问题

在本次测试中，影响应用并发性能主要体现在长连接持有时间，当服务器处理某个请求耗时较长会导致并发能力直线下降，这个耗时可能会因为数据库长事务、长计算、或发起对外慢速同步的API请求等等原因导致。

5.2 、排查

通过druid monitor监控可以查看很多与数据库连接的参数和实际发生状态，本例中，主要需要找到事务时间分布和连接持有时间即可初步定位问题，然后通过SQL监控找到发生的SQL语句逐步排查定位到JAVA代码块，找到代码块一般都能分析出实际的问题。

5.3、核心

在整个应用生态中，最宝贵的资源就是数据库连接，数据库相关业务密集的系统中，首先需要保证尽可能少的持有数据库连接。所以才催生出数据库连接池这些技术。第二宝贵的是磁盘IO，所有对磁盘IO的操作尽可能少，所以催生出数据库索引、缓存等技术，对于需要直接操作磁盘IO的计算来说，能用顺序读或写，就不要用随机读或写。

5.4、调优

优化并发需从几个方面出发：

服务器本身的参数，比如CPU核数，高性能磁盘位置等，通过服务器参数对应设置前文所述的几个应用参数，比如服务器CPU核心数为16个，一般通用业务应用下，缺省的200个线程已经足够。
一旦确认服务器配置等基本的参数，并拍脑袋设置了一些应用参数后，就需要启动压测测试各参数配比下最好的服务器和应用性能。
确认你的业务系统是计算密集型还是IO密集型，针对性的编写测试用例。
最后确认业务系统乃至服务器的性能瓶颈链，输出整体性能报告。在实际生产中，一旦检测到实际并发与性能报告相差太大就可以启动排查程序。

6、优化实验

6.1 手动事务

代码优化背景和目标：

首先长连接的事实不可改变，因为有可能这个计算或调用就是需要耗费5秒的时间，如果能减少，则属于另外的优化逻辑；
在这个背景下，我们改善的目标是减少数据库连接的持有时间；
从实例代码里，真正需要事务的操作是两个insert，slowMethod和query查询都不需要，所以启动手动事务就可以减少数据库连接的持有时间。
使用Springboot的手动事务模板。

6.2、优化第一组测试

代码优化如下：

	@Resource
    private TransactionTemplate transactionTemplate;

	@Override
    public List<TestUser> optimizedGetAll() {
        slowMethod(customProperties.getSlowMillis());
        TestUser user1 = getTestUser("王五", "jack");
        TestUser user2 = getTestUser("赵柳", "amy");

        transactionTemplate.execute(status -> {
            this.testUserDao.insert(user1);
            this.testUserDao.insert(user2);
            return Boolean.TRUE;
        });

        return this.testUserDao.queryByBlurry(user2);
    }

druid连接池主要结果分析：

指标	值	解释
事务时间分布	0,0,2295,1626,79,0,0	事务运行时间分布，分布区间为[0-1 ms, 1-10 ms, 10-100 ms, 100-1 s, 1-10 s, 10-100 s, >100 s]
连接持有时间分布	2307,1041,2735,1838,79,0,0,0	连接持有时间分布，分布区间为[0-1 ms, 1-10 ms, 10-100 ms, 100ms-1s, 1-10 s, 10-100 s, 100-1000 s, >1000 s]

在JMeter中的吞吐量为：37.3/second

测试分析：

首先连接持有时间大幅度下降，原先慢速组100%的样本数据在1-10 s区间，现在改区间只有0.98%的数据。
我们发现连接持有时间分布样本数据总和是8000，而不是原本慢速组的4000，并且在0-1 ms, 1-10 ms, 10-100 ms, 100ms-1s都有分布，说明一个问题，query查询单独占用了数据库连接。
我们知道数据库连接是宝贵资源，query单独占用连接是否有问题？从上面的测试结果分析，query虽然单独占用资源，但是时间很短，并且也是复用了连接池的资源，相当于把长事务分摊到短操作中。是否还有更优配置呢？
所以我们还需要做一组测试，把query放入事务中试试看。本次连接持有时间分布总样本中位数参考值是 1458262 ms。
最后，吞吐量有所提升，总体上这个优化方案是有效果的。

6.3、优化第二组测试