目录

• 一、笔者前言
• 二、正菜开始
• 三、假设你的服务有1万并发的访问
• 四、为啥有这种效果?
• 五、其他应该考虑到的因素
• 六、连接数计算公式
• 七、结论：你需要的是一个小连接池，和一个等待连接的线程队列
• 八、额外需要注意的点

一、前言

基本上来说，大部分项目都需要跟数据库做交互，那么，数据库连接池的大小设置成多大合适呢？

一些开发老鸟可能还会告诉你：没关系，尽量设置的大些，比如设置成 200，这样数据库性能会高些，吞吐量也会大些！

你也许会点头称是，真的是这样吗？看完这篇文章，也许会颠覆你的认知哦！

二、正菜开始

可以很直接的说，关于数据库连接池大小的设置，每个开发者都可能在一环节掉进坑里，事实上呢，大部分程序员可能都会依靠自己的直觉去设置它的大小，设置成 100 ？思量许久后，自顾自想，应该差不多吧？

三、假设你的服务有1万并发的访问

不妨意淫一下，你手里有个网站，并发压力虽然还没到 Facebook 那个级别，但是呢？也有个1万上下的并发量！也就是说差不多2万左右的 TPS。

那么问题来了！这个网站的数据库连接池应该设置成多大合适呢？

其实这个问法本身就是有问题的，我们需要反过来问，正确问法应该是：

“这个网站的数据库连接池应该设置成多小合适呢？”

PS: 这里有一个 Oracle 性能小组发布的简短视频，链接地址为 http://www.dailymotion.com/video/x2s8uec，友情提示，需要科学上网才能访问哦！

口述一下，视频中对 Oracle 数据库进行了压力测试，模拟 9600 个并发线程来操作数据库，每两次数据库操作之间 sleep 550ms，注意，视频中刚开始设置的线程池大小为 2048。

让我们来看看数据库连接池的大小为 2048 性能测试结果的鬼样子：

每个请求要在连接池队列里等待 33ms，获得连接之后，执行SQL需要耗时77ms, CPU 消耗维持在 95% 左右；

接下来，我们将连接池的大小改小点，设置成 1024，其他测试参数不变，结果咋样？

"这里，获取连接等待时长基本不变，但是 SQL 的执行耗时降低了！"

哎呦，有长进哦！

接下来，我们再设置小些，连接池的大小降低到 96，并发数等其他参数不变，看看结果如何：

每个请求在连接池队列中的平均等待时间为 1ms, SQL 执行耗时为 2ms.

我去！什么鬼？

我们没调整任何东西，仅仅只是将数据库连接池的大小降低了，这样，就能把之前平均 100ms 响应时间缩短到了 3ms。吞吐量指数级上升啊！

你这也太溜了！