Зачем пул: цена создания соединения

Junior-сервис открывает свежее соединение с Postgres на каждый запрос, делает один быстрый SELECT и закрывает его. Запрос занимает 1 мс; обработка занимает 35. Недостающие 34 мс — чистый setup: TCP-рукопожатие, TLS-рукопожатие и база, аутентифицирующая пользователя и форкающая backend-процесс — каждый раз, выброшенное после одного запроса. Под нагрузкой база тратит больше CPU на создание и уничтожение соединений, чем на ответы. Никто не написал медленный запрос. Написали быстрый запрос, обёрнутый в дорогой ритуал, повторяемый на каждом запросе.

Соединение дорого создавать

Новичку соединение с базой кажется бесплатным — вызови connect(), получи объект. Под капотом открытие одного — цепочка медленных шагов:

• TCP-рукопожатие — круговой обмен для установки сокета (один RTT до того, как потекут байты).
• TLS-рукопожатие — настройка шифрования, 2 круговых обмена на TLS 1.3, 3 на TLS 1.2; на канале с реальной задержкой это одно — десятки-сотни миллисекунд.
• Аутентификация — база проверяет учётные данные, часто со своим challenge/response-обменом.
• Выделение backend — Postgres форкает выделенный OS-процесс на соединение; MySQL порождает поток. Этот процесс резервирует память (~2–3 МБ общей/служебной памяти до того, как выполнит хоть один запрос).

Так что соединение — не дешёвая ручка, это TCP-сокет плюс TLS-сессия плюс живой серверный процесс. Создавать и сносить его на запрос значит платить всё это за работу в один запрос.

Пул амортизирует цену

Пул соединений — небольшой долгоживущий набор уже открытых соединений, держимых наготове. Вместо connect → query → close поток становится:

1. Взять (acquire/borrow) готовое соединение из пула.
2. Выполнить запрос на нём.
3. Вернуть (release) его в пул — не закрыть, лишь пометить свободным для следующего запроса.

Дорогие рукопожатия случаются раз, когда пул наполняется, затем те же соединения переиспользуются тысячи раз. Это амортизация: фиксированная цена setup, размазанная по многим использованиям, пока доля на запрос не станет ничтожной. Запрос теперь платит ~0 мс setup вместо ~34, а база перестаёт жечь CPU на churn соединений.

Пул — это ещё и лимит

Переиспользование — очевидная польза, но вторая работа пула важна не меньше: это граница. Пул размера 20 значит, что от этого сервиса к базе одновременно существует не более 20 соединений, сколько бы запросов ни пришло. Этот потолок — фича: он защищает базу, которая может держать лишь столько backend-ов, прежде чем упадёт (Postgres по умолчанию max_connections = 100). Без пула всплеск в 5 000 конкурентных запросов попытался бы открыть 5 000 соединений, и база отвергла бы их «too many clients». Пул превращает неограниченный спрос в фиксированное, выживаемое число — та же идея ограниченной конкурентности из прошлого юнита, применённая к самому дорогому downstream-ресурсу бэкенда.