数据库调优-连接池优化

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第2天，点击查看活动详情

1.写在前面

在昨天的时候，我们就谈到了数据库调优原理和分享了JMeter数据库压力测试案例

详情可参考这里：点击查看

经过昨天的分析，我们已经基本掌握了如何通过JMeter压测工具，对mysql数据库进行压力测试。

那我们今天继续往下进行测试：连接池优化

说到连接池优化，可能大部分人都是比较蒙，毕竟在开发的过程中，也是很少关注过这一块配置。

哈哈，基于实际的情况，要想成为一个大牛，对数据库的优化，我们还是得多多少少掌握一点的。

那废话不多说，直接上！！！

首先，先贴下连接池的相关配置：

连接池参数配置：

字段	含义
Max Number of Connections	最大连接数；做性能测试时，可以填 0 。在开发的项目中按实际代码填写，默认是 20 。
Max Wait(ms)	在连接池中取回连接最大等待时间，单位毫秒
Time Between Eviction Runs(ms)	线程可空闲时间，单位毫秒如果当前连接池中某个连接在空闲了 time Between Eviction Runs Millis 时间后任然没有使用，则被物理性的关闭掉
Auto Commit	自动提交sql语句，如：修改数据库时，自动 commit
Transaction isolation	事务隔离级别
Preinit Pool	立即初始化连接池如果为 False，则第一个 JDBC 请求的响应时间会较长，因为包含了连接池建立的时间

Transaction Isolation：事务间隔级别设置，主要有如下几个选项：（对JMX加解密）
- TRANSACTION_NODE 事务节点
- TRANSACTION_READ_UNCOMMITTED 事务未提交读
- TRANSACTION_READ_COMMITTED 事务已提交读
- TRANSACTION_SERIALIZABLE 事务序列化
- DEFAULT 默认
- TRANSACTION_REPEATABLE_READ 事务重复读、

看到这，有些小伙伴，可能要溜了，别慌，且听我一一道来！！！上干货，安排。。。

2.连接池优化

加不加连接池，对当前服务性能产生什么影响？

单个服务也会耗尽连接？

会不会对性能产生影响呢？会扣 1 ，不会扣 2 ，性能会变好扣 3

最大连接数越大是不是性能越好呢？

获取池中连接的最大等待时长？等待时间越短越好呢？

2.1JMeter优化

看到这里，是不是有点眼熟？

就是刚贴的，连接池参数配置

这里我们先对JMeter进行优化下，字体和外观。

切换到中文

找到jmeter.properties文件，添加下面配置：

language=zh_CN

然后重启下JMeter即可。

外观，有黑色改成白色

2.2 不使用连接池

有什么问题呢？会报错

如果你不是多个应用程序同时连接MySQL，问题不大。但是如果你是多个应用程序连接数据库。

每个应用并发去获取数据库连接，会导致连接耗尽，资源争抢冲突！

这里，我们创建一个计划，去测试下：

线程数： 20

ramp-up： 1

循环次数： 2000

执行，查看结果树

可以看到，当不使用线程池时，很快，就报下面这个错了：

Response message:java.sql.SQLException: Cannot create PoolableConnectionFactory (Data source rejected establishment of connection, message from server: "Too many connections")

查看聚会报告

2.3 连接池参数设置

压力测试连接池参数设置：

2.3.1 MaxWait

参数表示从连接池获取连接的超时等待时间，单位毫秒。

注意：这个参数只管理获取连接的超时。获取连接等待的直接原因池子里没有可用连接，具体包括如下四种情况：

连接池未初始化
连接长久未使用已被释放，
连接使用中需要新建连接
连接池已耗尽需等待连接用完后归还

这里有一个很关键的点是 maxWait 未配置或者配置为 0 时，表示不设等待超时时间。也就是无限制等待

如果不配置maxWait，后果会怎么样呢？可能有些应用就这么干，来做个案例：

maxWait=0,
maxActive=5,

对应JMeter的配置如下：

正常流量下业务没有发现任何问题，但突发大流量涌入时，造成连接池耗尽，所有新增的DB请求处于等待获取连接的状态中。

由于 maxWait=0 表示无限等待，在请求速度大于处理速度的情况下等待队列会越排越长，最终业务上的表现就是业务接口大量超时，流量越大造成实际吞吐量反而越低。

线程数 5 ：

1658996535095(1).jpg

异常率：38%

线程数 10 ：

异常率：50%

线程数 20 ：

异常率：62%

由上可见，很明显，随着线程数增加，异常率不断增加。

配置建议：如果在内网，网络情况良好的情况下，maxWait应该设置为 800 毫秒。如果在外网，网络状况不佳值可以设置为 1200 毫秒。TCP重连的时间是 1 秒。

如果MaxWait值很大，会出现高并发情况下，获取不到连接，响应时间变长，吞吐量下降
如果Maxwait值很小，会出现吞吐量奇高，但是异常数也奇高。

重点了，兄弟们。

maxWait，配置，get！！！

2.3.2 MaxActive

线程数： 20
ramp-up： 1
循环次数： 2000

最大连接池数量，允许的最大同时使用中的连接数。

注意：配置 maxActive 千万不要好大喜多，虽然配置大了看起来业务流量飙升后还能处理更多的请求，但切换到DB视角会发现其实连接数的增多在很多场景下反而会减低吞吐量，一个非常典型的例子就秒杀，在更新热点数据时DB 需要加锁操作，这个时候再让更多的连接操作DB就有点像假日往高速上涌入的车辆，只会给DB添堵。

最大连接： 10

最大连接数： 20

最大连接数： 30

配置建议：大多数场景下，配置 20 即可，足够使用的！建议结合实际业务场景设置，在业务系统稳定运行一段时间之后，获取稳定连接数，在这个基础之上乘以3-4即可！

为什么最大连接数设置的过多并不是一件好事？ 是不是设置的连接数越多，性能就越好呢？不是！

首先，数据库的连接是非常宝贵的资源，很有限？数据库的最大连接数是多少？ 151 个
其次， 20 个连接足以支持到足够的TPS
再次，如果设置最大的连接数过多了，会造成资源争抢。从而出现服务器报错！设置连接过多，没有提升性能反而性能下降
在绝大多数业务场景下， 10 、 20 、 30 都足以支撑！

哈哈，这个参数，很重要喔，不记下来嘛？

# 查看数据库最大支持的连接数
SHOW variables like 'max_connections';  //151
# 查看数据库最大使用的连接数
SHOW variables like 'max_user_connections';  //0

2.4 连接属性设置

之前在配置JDBC的连接池的时候讲过两个参数：serverTimezone=UTC&characterEncoding=utf-8。

接下来再说两个参数在网络方面有很大作用；主要应对在网络异常模式下，数据库无法释放连接的问题；

connectTimeout： 表示等待和MySQL数据库建立socket链接的超时时间。
- 如果与服务器(这里指数据库)请求建立连接的时间超过ConnectionTimeOut，就会抛连接超时异常，即服务器连接超时。
socketTimeout： 表示客户端和MySQL数据库建立socket后，读写socket时的等待的超时时间
- 如果与服务器连接成功，就开始数据传输了。如果服务器处理数据用时过长，超过了SocketTimeOut，就会抛出SocketTimeOutExceptin，即服务器响应超时，服务器没有在规定的时间内返回给客户端数据。

jdbc:mysql://localhost:3306/dbname?serverTimezone=UTC&characterEncoding=utf-8&connectionTimeout=3000&socketTimeout=1200

解释：

一个请求包含三个过程：1.建立连接，2,数据传输，3.断开连接
connectTimeout默认值 0 ，你连接超时。
socketTimeout默认值，采用Linux操作系统的配置，默认值 30 分钟。

建议配置：connectTimeout 3000，socketTimeout 1200

哈哈，这里还是直接mark下吧！！！

好了，以上就是我个人的实操了。

个人理解，可能也不够全面，班门弄斧了。

好了，今天就先到这里了！！！^_^

后面的分享，就留在下次了，掰掰。

如果觉得有收获的，帮忙点赞、评论、收藏一下呗！！！