昨天介紹什麼是 max_connections ，今天就來介紹 max_connections 可能會造成的資料庫連線數瓶頸，並以實際壓測來說明會發生什麼事，實驗步驟會包括事先準備、設計和設定腳本，以及最後的測試結果。

調整 max_connections

為了可以更簡易的測試出瓶頸，在 postgresql.conf 中把 max_connections 的設定調低。

調整後需重啟 PostgreSQL

brew services restart postgresql

設計 JMeter 測試腳本

• 設定 Thread Group
• 在 Thread Group 底下設定底下設定 JDBC Request
• 在 JDBC Request 底下設定 JDBC Connection ，並指定最大連線數和 SQL statement
  
• 在JDBC Request底下設定 View Results Tree

測試結果

在既有的 connection 數為 2 ，和 JMeter 的最大連線數設為 3 的情況下，超過前面 max_connections 設定的 4 ，所以 JMeter 收到 Error preloading the connection pool 的錯誤訊息。

把 JMeter 的最大連線數改為 1 ，就可以看到資料庫的連線正常。

結論

藉由 JMeter 壓力測試，我們可以清楚看到 max_connections 這個限制帶來的 Auto Scaling 天花板。當然，我們也可以提高 max_connections 的設定，但必須要有監控機制，確保安裝 PostgreSQL 的機器，不會產生效能問題，導致整個系統崩潰。

所以當我們在設計 Auto Scaling 架構時，別忘了把資料庫連線數的瓶頸也考慮進去，不然會造成系統無法正常存取資料！