一 概述
我在複習數據連接池的時候，發現有一遍文章就是講數據庫連接池的內容，主要是講HikariCP（一個數據庫連接池），看完這篇文章後讓我慢慢學會了從計算機系統基礎角度考慮數據庫線程池的問題，受益匪淺。原文章爲英文，該博客對其進行了翻譯。數據庫連接池的配置是開發者們常常搞出坑的地方，在配置數據庫連接池時，有幾個可以說是和直覺背道而馳的原則需要明確。
二 10000併發用戶訪問
想象你的一個網站，壓力雖然還沒到Facebook那個級別，但也有個1萬上下的併發用戶進行訪問——也就是說差不多2萬左右的TPS(Transation per second)。那麼這個網站的數據庫連接池應該設置爲多少才能使得網站性能比較好呢？
請先看Oracle Real World Performance Group發佈的與數據庫連接池相關的視頻：視頻地址鏈接
該視頻內容爲針對Oracle數據庫進行的壓力測試，在併發線程爲9600的情況下進行數據庫操作，每兩次訪問數據庫的操作之間sleep 550ms，一開始設置的中間件線程池大小爲2048，配置信息如下：
在此次線程池大小爲2048的壓力測試下的數據庫性能數據爲，每個請求要在連接池隊列裏等待33ms，獲得連接後執行SQL需要77ms。
於此同時，數據庫會出現很多等待事件。
連接池大小降爲96
把數據庫連接池大小降爲96，併發線程數仍然是9600不變，隊列平均等待1ms，執行SQL平均耗時2ms。
其實並沒有沒有進行其他任何調整，僅僅只是縮小了中間件層的數據庫連接池的數量，wait事件幾乎沒了，但是吞吐量上升了，而且請求響應時間有了明顯的縮短。
三 其中的原因是什麼
類比思考：爲什麼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時的效果如何尚未有分析。
按這個公式，你的6核i5數據庫服務器的連接池大小應該爲((6 * 2) + 1) = 13。跑個性能測試試一下，我們保證它能輕鬆搞定3000用戶以6000TPS的速率併發執行簡單查詢的場景。如果連接池大小超過13，你會看到響應時長開始增加，TPS開始下降。
筆者注：這一公式其實不僅適用於數據庫連接池的計算，大部分涉及計算和I/O的程序，線程數的設置都可以參考這一公式。我之前在對一個使用Netty編寫的消息收發服務進行壓力測試時，最終測出的最佳線程數剛好是CPU核心數的一倍。
公理：你需要一個小連接池，和一個充滿了等待連接的線程的隊列
如果你有10000個併發用戶，設置一個10000的連接池基本等於失了智。1000仍然很恐怖。即是100也太多了。你需要一個10來個連接的小連接池，然後讓剩下的業務線程都在隊列裏等待。連接池中的連接數量應該等於你的數據庫能夠有效同時進行的查詢任務數（通常不會高於2*CPU核心數）。
我們經常見到一些小規模的web應用，應付着大約十來個的併發用戶，卻使用着一個100連接數的連接池。這會對你的數據庫造成極其不必要的負擔。
六 注意點
- 連接池的大小最終與系統特性相關。
- 比如一個混合了長事務和短事務的系統，通常是任何連接池都難以進行調優的。最好的辦法是創建兩個連接池，一個服務於長事務，一個服務於短事務。
- 再例如一個系統執行一個任務隊列，只允許一定數量的任務同時執行，此時併發任務數應該去適應連接池連接數，而不是連接池連接數去適應併發任務數。