Запрос на соединение без пула довольно тяжелый: вы должны создать новое соединение, использовать его и закрыть.
Пул соединений устраняет большую часть накладных расходов, так как большинство запросов не будет стоить затрат на создание соединения (самая тяжелая часть управления соединениями) или затрат на его закрытие. Однако каждый запрос к базе данных будет использовать соединение (поэтому ваше второе обновление определенно использует соединение). Все, что делает пул, - это создает для вас соединения от вашего имени и позволяет вам использовать их повторно, поэтому «соединение с базой данных» и «соединение с пулом» на самом деле одно и то же.
Обычно вы настраиваете пул с минимальным количеством соединений. Например, вы можете настроить его так, чтобы всегда было как минимум пять подключений. Когда ваше приложение запускается, пул распределяет эти соединения до того, как поступят любые запросы. По мере поступления каждого запроса пул выдает уже открытое соединение для использования по запросу. Когда соединение установлено, оно должно быть возвращено обратно в пул кодом, который его заимствовал. Если в ваше приложение поступает много одновременных запросов, у вас могут закончиться соединения. Это где другие политики в пуле соединений.
Обычно есть настройка для того, что делать, когда у вас заканчиваются соединения (все соединения передаются в запросы), например, «создать еще 1 подключение» или «создать еще 5 подключений». Таким образом, если имеется только 5 подключений в пуле и поступает шестой параллельный запрос, вероятно, будут возникать некоторые затраты, пока пул создает одно или несколько дополнительных подключений. Тем не менее, после создания у вас теперь есть пул, который увеличился для быстрого размещения большего количества соединений на период занятости.
Точно так же, если количество поступающих запросов замедлилось (возможно, в ночное время), у вас может быть куча незанятых соединений, находящихся в пуле. У пулов обычно есть настраиваемая политика для того, что делать с простаивающими соединениями. Например, вы можете сказать, что хотите иметь не более 5 неактивных соединений в пуле, и вы считаете соединение «неактивным», если оно не использовалось в течение последних 5 минут. Затем пул закроет соединения, чтобы уменьшить пул до меньшего размера, освобождая ненужные ресурсы.
Другая политика, которую вы можете установить, - это максимальное количество подключений, которые разрешено иметь в пуле. В вашем примере это значение равно 8. Что означает, что приложение неважно, вы никогда не допустите более 8 одновременных запросов к базе данных. Здесь вступает в действие другая политика: что делать, если у вас закончились соединения и вам не разрешено наращивать пул. Обычно пул предоставляет несколько вариантов, например «ждать свободного соединения», «создавать больше подключений», «генерировать исключение» и т. Д. Поскольку в вашем примере «максимальное ожидание» равно -1, это должно означать значение по умолчанию: Ваш пул должен ждать соединения столько времени, сколько потребуется (при условии, что -1 означает «навсегда»). В зависимости от вашего приложения это может быть хорошим или плохим выбором.
В общем, я думаю, что со временем вы отслеживаете, сколько времени занимают запросы, сколько подключений у вас одновременно и т. Д., И настраиваете параметры пула, чтобы сделать их наиболее эффективными, то есть минимизировать время ожидания для создания / заимствования подключения минимизируйте количество ресурсов, выделяемых для соединений, и быстро реагируйте на изменение шаблонов запросов.
Наконец, что касается вашего вопроса, вы можете иметь 0 незанятых и 0 активных соединений, если ваш пул настроен на агрессивное закрытие соединений. Попробуйте установить минимальный размер пула, чтобы увеличить это.