Сначала необходимо определить, что будет делать пул, если поступит запрос, и нет свободного соединения для его обслуживания. Это исключение? Вернуть ноль? Блокировать, пока другое соединение не будет возвращено в пул?
Как только вы узнаете, что произойдет, когда емкость будет превышена, подумайте, как вы могли бы справиться с этим в вызывающем коде, и в каких ситуациях это допустимо. В какой-то момент, когда количество подключений возрастет, вам придется отказаться от обслуживания некоторых запросов, но только вы можете решить, что это за точка. Фактическая точка зависит от многих факторов, включая такие вещи, как
- ваши текущие частоты запросов ожидания и занятости
- волатильность этих ставок (вам нужно больше «передышки», если ставки сильно скачут)
- любые будущие прогнозы увеличения емкости по сравнению с аппаратными усовершенствованиями и затратами времени разработчиков на пересмотр этого кода (если вы планируете обновить его через пару месяцев, вам потребуется меньше накладных расходов, чем если бы он продолжал работать для пару лет)
- любые гарантии, которые ваша компания дает в отношении мощности обработки
- способность клиентов понимать запросы «попробуйте позже» - например, если вы знаете, что на другом конце это автоматический сценарий, который спит минуту на 503 и пытается снова, это лучше, чем человек, получающий сообщение «емкость временно превышена», и оба гораздо лучше, чем пакетный сценарий, который получает не 200 ответ и просто выходит с ошибкой.
- срочность запросов - некоторые запросы (глядя на изображения котят) могут быть разумно отложены, а другие (заказы на торговлю акциями) могут быть очень чувствительными ко времени.
И так далее, и тому подобное.
Надеемся, что из вышеперечисленного вы сможете определить количество запросов, которые вам необходимо обрабатывать одновременно (и если есть различные типы запросов, возможно, вам придется принять это во внимание беспокойство тоже). Тогда вам нужно просто посмотреть, как входящие запросы получают и использовать соединения, рассуждать и профилировать, пока не обнаружите количество соединений в пуле, необходимое для поддержания вашей целевой скорости соединений.
Не забудьте учесть такие вещи, как потоки без запросов (например, рабочие пулы), получающие свои собственные соединения из того же пула (пул должен быть больше), а также запросы, удерживающие соединение только для части их выполнения. (бассейн может быть меньше).