對於非集中連接的請求相當重要:您必須創建一個新連接,使用它並關閉它。
連接池消除了大部分開銷,因爲大多數請求不會產生創建連接的成本(連接管理的最重要部分)或關閉成本。但是,對數據庫的每個請求都將使用一個連接(因此您的第二個更新肯定使用連接)。所有池都是以你的名義爲你創建連接,並允許你重用它們 - 所以「數據庫連接」和「池連接」實際上是一回事。
通常情況下,您可以使用最少的連接數配置池。例如,您可以將其配置爲始終至少有五個連接。當您的應用程序啓動時,池會在任何請求進入之前分配這些連接。當每個請求進入時,池會放出一個已經打開的連接供請求使用。使用連接完成後,它應該通過借用它的代碼返回到池中。如果你的應用程序有很多併發請求進來,你可能會用完連接。這是連接池中的其他策略進來的地方。
通常有一個設置,用於在連接用完時(所有連接都借出請求)執行的操作,例如「創建1個以上的連接」或「再創建5個連接「。因此,如果只有5個池連接並且有第六個併發請求進入,那麼在池創建一個或多個附加連接時可能會產生一些成本。但是,一旦創建,您現在擁有一個已經發展壯大的游泳池,可以在忙碌的一段時間內快速適應大量的連接。
同樣,如果進入的請求數量減少(也許是夜間),您現在可能會有一堆閒置連接位於池中。池通常有一個可配置的策略來處理空閒連接。例如,您可能會說您只需要在池中最多有5個空閒連接,並且如果連接在最近5分鐘內未使用,則認爲連接「空閒」。然後池會關閉連接,將池縮小到更小的尺寸,釋放不需要的資源。
您可以設置的另一個策略是池允許的最大連接數。在你的例子中,你將這個設置爲8.這意味着無論你的應用程序有多忙,你永遠不會允許超過8個併發數據庫請求。這就是另一種政策的出現:當你連接不足並且不允許增加池時該怎麼辦。通常,池會提供多種選擇,例如「等待一個空閒連接」,「建立更多連接」,「拋出異常」等等。由於您的示例具有-1的「最大等待時間」,因此必須表示默認值你的游泳池需要等待一段時間的連接(假設-1意味着「永遠」)。根據您的應用程序,這可能是一個好的或不好的選擇。一般來說,我認爲隨着時間的推移,你會監測請求需要多長時間,你有多少次連接,並且調整你的池設置最有效率,也就是說最小化創建/借用a的等待時間連接,儘量減少分配給連接的資源數量,並快速響應不斷變化的請求模式。
最後,關於您的問題,如果您的池配置爲主動關閉連接,則可以有0個空閒連接和0個活動連接。嘗試設置最小池大小以增加此值。