数据库链接池的配置是开发者们经常搞出坑的地方，在配置数据库链接池时，有几个能够说是和直觉背道而驰的原则须要明确。nginx
1万并发用户访问web
想象你有一个网站，压力虽然还没到Facebook那个级别，但也有个1万上下的并发访问——也就是说差很少2万左右的TPS。那么这个网站的数据库链接池应该设置成多大呢？结果可能会让你惊讶，由于这个问题的正确问法是：数据库
“这个网站的数据库链接池应该设置成多小呢？” 下面这个视频是Oracle Real World Performance Group发布的，请先看完：http://www.dailymotion.com/video/x2s8uec缓存
（由于这视频是英文解说且没有字幕，我替你们作一下简单的归纳：） 视频中对Oracle数据库进行压力测试，9600并发线程进行数据库操做，每两次访问数据库的操做之间sleep 550ms，一开始设置的中间件线程池大小为2048： 
初始的配置服务器
压测跑起来以后是这个样子的： 2048链接时的性能数据网络
每一个请求要在链接池队列里等待33ms，得到链接后执行SQL须要77ms并发
此时数据库的等待事件是这个熊样的： 各类buffer busy waitside
各类buffer busy waits，数据库CPU在95%左右（这张图里没截到CPU）性能
接下来，把中间件链接池减到1024（并发什么的都不变），性能数据变成了这样： 链接池降到1024后测试
获取连接等待时长没怎么变，可是执行SQL的耗时减小了。下面这张图，上半部分是wait，下半部分是吞吐量 wait和吞吐量
能看到，中间件链接池从2048减半以后，吐吞量没变，但wait事件减小了一半。
接下来，把数据库链接池减到96，并发线程数仍然是9600不变。 96个链接时的性能数据
队列平均等待1ms，执行SQL平均耗时2ms。 wait事件几乎没了，吞吐量上升。
没有调整任何其余东西，仅仅只是缩小了中间件层的数据库链接池，就把请求响应时间从100ms左右缩短到了3ms。
But why?
为何nginx只用4个线程发挥出的性能就大大超越了100个进程的Apache HTTPD？回想一下计算机科学的基础知识，答案实际上是很明显的。
即便是单核CPU的计算机也能“同时”运行数百个线程。但咱们都[应该]知道这只不过是操做系统用时间分片玩的一个小把戏。一颗CPU核心同一时刻只能执行一个线程，而后操做系统切换上下文，核心开始执行另外一个线程的代码，以此类推。给定一颗CPU核心，其顺序执行A和B永远比经过时间分片“同时”执行A和B要快，这是一条计算机科学的基本法则。一旦线程的数量超过了CPU核心的数量，再增长线程数系统就只会更慢，而不是更快。
这几乎就是真理了……
有限的资源
上面的说法只能说是接近真理，但还并无这么简单，有一些其余的因素须要加入。当咱们寻找数据库的性能瓶颈时，老是能够将其归为三类：CPU、磁盘、网络。把内存加进来也没有错，但比起磁盘和网络，内存的带宽要高出好几个数量级，因此就先不加了。
若是咱们无视磁盘和网络，那么结论就很是简单。在一个8核的服务器上，设定链接/线程数为8可以提供最优的性能，再增长链接数就会因上下文切换的损耗致使性能降低。数据库一般把数据存储在磁盘上，磁盘又一般是由一些旋转着的金属碟片和一个装在步进马达上的读写头组成的。读/写头同一时刻只能出如今一个地方，而后它必须“寻址”到另一个位置来执行另外一次读写操做。因此就有了寻址的耗时，此外还有旋回耗时，读写头须要等待碟片上的目标数据“旋转到位”才能进行操做。使用缓存固然是可以提高性能的，但上述原理仍然成立。
在这一时间段（即"I/O等待"）内，线程是在“阻塞”着等待磁盘，此时操做系统能够将那个空闲的CPU核心用于服务其余线程。因此，因为线程老是在I/O上阻塞，咱们可让线程/链接数比CPU核心多一些，这样可以在一样的时间内完成更多的工做。
那么应该多多少呢？这要取决于磁盘。较新型的SSD不须要寻址，也没有旋转的碟片。可别想固然地认为“SSD速度更快，因此咱们应该增长线程数”，偏偏相反，无需寻址和没有旋回耗时意味着更少的阻塞，因此更少的线程[更接近于CPU核心数]会发挥出更高的性能。只有当阻塞创造了更多的执行机会时，更多的线程数才能发挥出更好的性能。
网络和磁盘相似。经过以太网接口读写数据时也会造成阻塞，10G带宽会比1G带宽的阻塞少一些，1G带宽又会比100M带宽的阻塞少一些。不过网络一般是放在第三位考虑的，有些人会在性能计算中忽略它们。 上图是PostgreSQL的benchmark数据，能够看到TPS增加率从50个链接数开始变缓。在上面Oracle的视频中，他们把链接数从2048降到了96，实际上96都过高了，除非服务器有16或32颗核心。
计算公式
下面的公式是由PostgreSQL提供的，不过咱们认为能够普遍地应用于大多数数据库产品。你应该模拟预期的访问量，并从这一公式开始测试你的应用，寻找最合适的链接数值。
链接数 = ((核心数 * 2) + 有效磁盘数)
核心数不该包含超线程(hyper thread)，即便打开了hyperthreading也是。若是活跃数据所有被缓存了，那么有效磁盘数是0，随着缓存命中率的降低，有效磁盘数逐渐趋近于实际的磁盘数。这一公式做用于SSD时的效果如何还没有有分析。
按这个公式，你的4核i7数据库服务器的链接池大小应该为((4 * 2) + 1) = 9。取个整就算是是10吧。是否是以为过小了？跑个性能测试试一下，咱们保证它能轻松搞定3000用户以6000TPS的速率并发执行简单查询的场景。若是链接池大小超过10，你会看到响应时长开始增长，TPS开始降低。
笔者注：这一公式其实不只适用于数据库链接池的计算，大部分涉及计算和I/O的程序，线程数的设置均可以参考这一公式。我以前在对一个使用Netty编写的消息收发服务进行压力测试时，最终测出的最佳线程数就恰好是CPU核心数的一倍。
公理：你须要一个小链接池，和一个充满了等待链接的线程的队列
若是你有10000个并发用户，设置一个10000的链接池基本等于失了智。1000仍然很恐怖。便是100也太多了。你须要一个10来个链接的小链接池，而后让剩下的业务线程都在队列里等待。链接池中的链接数量应该等于你的数据库可以有效同时进行的查询任务数（一般不会高于2*CPU核心数）。
咱们常常见到一些小规模的web应用，应付着大约十来个的并发用户，却使用着一个100链接数的链接池。这会对你的数据库形成极其没必要要的负担。
请注意
链接池的大小最终与系统特性相关。
好比一个混合了长事务和短事务的系统，一般是任何链接池都难以进行调优的。最好的办法是建立两个链接池，一个服务于长事务，一个服务于短事务。
再例如一个系统执行一个任务队列，只容许必定数量的任务同时执行，此时并发任务数应该去适应链接池链接数，而不是反过来。
来源：kelgon jianshu.com/p/a8f653fc0c54