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

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

目录1、背景2、主要参数释义：2.1 tomcat主要并发参数释义2.2 数据库连接池参数2.3 数据库连接数3、测试程序4、jmeter测试4.1、快速组4.2、慢速组4.3、对照分析5、问题与优化5.1、问题5.2 、排查5.3、核心5.4、调优6、优化实验6.1 手动事务6.2、优化第一组测试6.3、优化第二组测试7、总结

1、背景

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

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

主要相关技术：

SpringBoot： 2.5.12mybatis-spring-boot-starter： 2.1.2druid-spring-boot-starter： 1.2.9mysql-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中默认http://是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

return Result.ok(testUserService.queryAll());

}

@GetMapping("/fastGetAll")

public Result

return Result.ok(testUserService.fastGetAll());

}

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

@Transactional(rollbackFor = Exception.class)

@Override

public List fastGetAll() {

TestUser user1 = getTestUser("李四", "jerry");

this.testUserDao.insert(user1);

slowMethod(customPropertieRKQcNMXKs.getFastMillis());

TestUser user2 = getTestUser("张三", "tom");

this.testUserDao.insert(user2);

return this.testUserDao.queryByBlurry(user2);

}

@Transactional(rollbackFor = Exception.class)

@Override

public List 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, 1RKQcNMXK0-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 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、优化第二组测试

代码优化如下：

@Override

public List optimizedGetAll2() {

slowMethod(customProperties.getSlowMillis());

TestUser user1 = getTestUser("王五", "jack");

TestUser user2 = getTestUser("赵柳", "amy");

return transactionTemplate.execute(new TransactionCallback>() {

@Override

public List doInTransaction(TransactionStatus status) {

testUserDao.insert(user1);

testUserDao.insert(user2);

return testUserDao.queryByBlurry(user2);

}

});

}

druid连接池主要结果分析：

指标值解释事务时间分布0,0,3778,222,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,2278,1611,111,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中的吞吐量为：38.0/second

测试分析：

对比一二组，首先事务分布时间是改善的，但是并不明显；本次连接持有时间分布总样本中位数参考值是 1474400 ms，对比一二组，第二组比第一组多耗费 16138 ms；在该样本的情况下，第一组实际持有连接的时间更短，压力更为平均。将不必要的query放入事务本身就是不推荐，本示例中query查询的数据量较小，如果数据量较大，从理论上分析，会明显影响事务的提交。吞吐量基本无变化，这个是符合预期的。所以这次优化，推荐使用第一组的方式。

7、总结

在系统初次上线前，可以考虑编写测试用例用压测的方式拿到服务器的性能指标。在系统完成开发后，可以考虑对简单、中等、高复杂度的API分别进行压测摸清API的性能体现，以及对比服务器性能指标，有可能在上线前就能排查出问题。在系统上线后，如果遇到应用性能下降或并发问题，可以通过观察连接池和SQL分析定位大致的java代码块，解决问题最终还是需要针对性编写测试用例再次复盘测试。大部分情况下，系统缺省的参数都够你使用，任何一次参数优化调整都应该有理论支撑和实践证明，云调参张口就来谁都会。并发调优一定要抓住关键目标，找到核心资源，分析并发瓶颈链路。数据库连接池还有很多参数是可以帮助调优分析的，本文没有介绍，jmeter的压测的方式也是多种多样，应根据不同的场景调整。并发调优是一个复杂的过程，从应用所有的关联点都可能出现问题，本文只是从开发角度，针对请求长连接以及数据库长事务做了简单的分析和推测。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。