dropwizard 连接mysql_数据库连接池连接数10？100？1000？的困惑
1. 开篇闲谈
基本上来说，大部分项目都需要跟数据库做交互，那么，数据库连接池的大小设置成多大合适呢？
一些开发老鸟可能还会告诉你：没关系，尽量设置的大些，比如设置成 200，这样数据库性能会高些，吞吐量也会大些！
的确如此，每次看到application.properties配置数据库连接池的时候，总是想要不再搞大一点连接数。
#整它个2000试试
spring.datasource.hikari.minimum-idle=2000
spring.datasource.hikari.maximum-pool-size=2000
然后发现，业务页面点点 也没啥区别，看看数据库的连接数的确上去了,但是发现大部分都在sleep:
1.png
2. 试验
探索真理的捷径莫过于动手，搞个demo，ab压测下看看，到底线程池连接数对请求响应会不会产生大影响。
2.1. 环境准备
一般mysql最大连接数比较少，提前设置下最大连接数
SET GLOBAL max_connections=2100
构建项目，新建Spring-boot web项目，添加如下Pom依赖
org.springframework.boot
spring-boot-starter-web
org.springframework.boot
spring-boot-starter-tomcat
org.springframework.boot
spring-boot-starter-undertow
mysql
mysql-connector-java
runtime
io.dropwizard.metrics
metrics-core
4.1.0
排除tomcat内嵌服务器，改用undertow，避免内嵌服务器性能影响。
配置数据库和连接池，采用牛逼的一匹的号称世界最快连接池：hikariCP
# 数据库连接配置
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/demo?serverTimezone=GMT%2b8&useUnicode=true&characterEncoding=utf8&useSSL=true
spring.datasource.username=root
spring.datasource.password=123456
# Hikari 连接池配置
spring.datasource.type=com.zaxxer.hikari.HikariDataSource
spring.datasource.hikari.minimum-idle=5
spring.datasource.hikari.maximum-pool-size=5
spring.datasource.hikari.auto-commit=true
spring.datasource.hikari.idle-timeout=30000
spring.datasource.hikari.pool-name=DatebookHikariCP
spring.datasource.hikari.max-lifetime=1800000
spring.datasource.hikari.connection-timeout=3000000
spring.datasource.hikari.connection-test-query=SELECT 1
当然提前得建一个库demo，和一张表up_user,且手工添加5000行数据
CREATE TABLE `up_user` (
`id` INT (11) PRIMARY KEY NOT NULL AUTO_INCREMENT,
`code` VARCHAR (36) NOT NULL,
`name` VARCHAR (60) NOT NULL,
`card_no` VARCHAR (100),
`email` VARCHAR (135),
`phone` VARCHAR (135),
`birthday` DATETIME ,
`gender` SMALLINT (6) DEFAULT 0,
`create_user` VARCHAR (36),
`create_time` DATETIME ,
`update_user` VARCHAR (36),
`update_time` DATETIME ,
`status` INT (2) DEFAULT 0,
`is_deleted` INT (2) DEFAULT 0,
`remark` VARCHAR(500) NULL
);
2.2. 测试服务编写
内置指标配置类
@Configuration
public class MetricsConfig {
@Bean
public MetricRegistry metrics() {
return new MetricRegistry();
}
@Bean
public Meter requestMeter(MetricRegistry metrics) {
return metrics.meter("request");
}
@Bean
public Timer responses(MetricRegistry metrics) {
return metrics.timer("executeTime");
}
@Bean
public ConsoleReporter consoleReporter(MetricRegistry metrics) {
return ConsoleReporter.forRegistry(metrics)
.convertRatesTo(TimeUnit.SECONDS)
.convertDurationsTo(TimeUnit.MILLISECONDS)
.build();
}
}
测试服务
@RestController
public class SqlTestController {
@Autowired
private HikariDataSource dataSource;
@Autowired
private Timer responses;
@RequestMapping("/one")
public String getSomeUser() throws SQLException, InterruptedException {
Connection connection = null;
PreparedStatement preparedStatement = null;
final Timer.Context context = responses.time();
String sql = "select * from up_user where id>"+new Random().nextInt(5000)+" limit 0,100";
try {
connection = dataSource.getConnection();
preparedStatement = connection.prepareStatement(sql);
preparedStatement.executeQuery();
} catch (SQLException e) {
e.printStackTrace();
} finally {
if(connection !=null){
connection.close();
}
if(preparedStatement !=null) {
preparedStatement.close();
}
TimeUnit.MILLISECONDS.sleep(200);
context.stop();
}
return "ok";
}
}
启动类
@SpringBootApplication
public class MetricsDemoApplication {
public static void main(String[] args) {
ApplicationContext ctx = SpringApplication.run(MetricsDemoApplication.class, args);
ConsoleReporter reporter = ctx.getBean(ConsoleReporter.class);
reporter.start(1, TimeUnit.SECONDS);
}
}
工具apache bench (安装略)
搞一台其他机器，进行压测，200线程并发，一共访问10000次
ab -c 200 -n 10000 http://10.30.21.8:9527/one?id=3
测试方案
线程池连接数5、100、1000
服务器机器 2核四线程
2.3. 测试结果
5个连接数：
5.png
100个连接数：
100.png
1000个连接数：
1000.png
3. 总结
对比发现三种情况下每秒请求个数，每个请求平均处理时间，整体1000个请求响应时间，其实3个差别不大。细微的变化:
3次测试请求的方差(stddev)，0.98 ->2.32->3.08
3次试验80%请求的响应时间，1299->1327->1357
由此得出：连接池的确不是越大越好，某些情况下差别不大，那么为什么这次实验性能差这么不明显呢，估计影响有两个：
笔者电脑为2核4线程PC，cpu对连接的处理切换，在多连接情况下不会太明显，没有8核16核那么大
压测量不够大，如果增大估计效果会更明显
所以，一般的服务器配置，其实10~20个连接数，其实就可以了，没有必要浪费了MySql的连接资源。
4. 后记
既然很多实战经验丰富的项目都推荐 连接池连接数：2*CUP+硬盘数，那么笔者心血来潮试了一把，一个连接数结果会怎么样：
1.png
方差(stddev):1.27 ，80%请求的响应时间：1318
显然和5个连接数比，的确性能有所下降。