Part1
问题背景
目前应用连接DB的连接数没有一个统一标准。目前既有应用的连接数设置普遍偏大，每个长连接都会产生开销，对DB服务器造成压力。随着服务的扩容和拆分，数据库服务端的压力会增大，有影响系统稳定性的风险。需要对数据库连接数建立标准，消除隐患。
Part 2
结论
数据连接数设置10个能达到单机500多TPS，满足一般的生产要求。建议新应用默认为此值。后续根据压测情况可再进行调整。
Part 3
科学法论证
问题
一个应用的数据库连接数设置多少合适？
假设&预测
根据业界的经验，一般应用的连接数设置在8～10之间。假设数据库连接数不是瓶颈，则将连接数设置为10比连接数设置为100，预测从影响应时间和吞吐量上没有明显的变坏趋势。
实验
单接口压测
压测结论
执行完2万个并发的时间，100个线程(连接数)用了39秒，10个线程(连接数)用了35秒。
具体数据
场景一
2024-04-25T23:23:53.481Z开启100个线程执行2万个并发，执行结束时间为：2024-04-25 23:24:32.003
场景二
2024-04-25T23:28:00.172Z重启service后，开启10个线程执行2万个并发，执行结束时间为：2024-04-25 23:28:35.430
链路压测
压测结论
单机数据库连接数在10及以下，性能没有明显的变坏。从吞吐量上反而有提升。
具体数据
之前线上压测过8000TPS，应用侧扩容服务器单个应用扩容到40～50台之间。基本可判定单机应用的TPS极限在200～350之间。所以压测上限也设定在此范围。
场景一
70个线程 ，最大线程数300，assert-app单机连接数达到100个(受限于容器线程数)。基本都在sleep状态(没有利用起来)，吞吐稳定在238/s左右。
场景二
70个线程 ，最大线程数10，assert-app单机连接数达到10个。也基本都在sleep状态，吞吐稳定在288/s左右。
场景三
70个线程 ，最大线程数5，assert-app单机连接数达到5个。也基本都在sleep状态，吞吐稳定在329/s左右。
分析
理论分析
数据库连接数本质上也是并发度的概念。并发度就和CPU核数紧密相关。咱们生产服务器一般是4C8G的，在这种配置下，数据库连接数取决于计算在数据库操作中的总占比。
比如，在《java并发编程实践》中有相应的公式。
不考虑IO，计算密集型的话，建议对于CPU密集型，设置为CPU核数+1。就是说设置5个数据库连接数是合理值。
对于IO密集型，有个公式：线程数= CPU的数量*目标CPU使用率* (1 + 等待时间/计算时间)。
如上面的数据库读写响应耗时。可以看到平均不到1ms。这种情况下，等待时间和计算时间都可以按照1ms来计算。CPU的数量为8*目标CPU使用率为0.6* (1 + 等待时间/计算时间结果为1)=8个数据库连接数。
事实上，对于数据库，一般会采用很高的配置，比如SSD硬盘，大内存（生产是16C32 G），这些都提高了数据库的读写性能，降低了数据库操作的延迟，使其更偏向于计算密集型。所以理论上设置连接数设置为10以内是个合理的数值。
压测分析
从压测结论：单机数据库连接数在10及以下，性能没有明显的变坏。从吞吐量上反而有提升。也验证了设置连接数设置为10以内是个合理的数值。
Part 4
总结
这次性能优化整体采用科学法的框架，采用理论结合实际进行问题分析。实际上，连接数过大对性能有反作用在很早之前就有人实验过。可参考数据库连接数设置多少合适？
