Часто спрашивают, а есть ли в Соколе "connection pool". Ну, типа, в любой серьезной СУБД такое должно быть.
Краткий ответ "нет и вам это не нужно", обычно не воспринимается как положительный.
Давайте, разбираться.
Рассмотрим ранее приведенные измерения TPC-C бенчмарка с разным количеством складов: 10К-1К.
Только сделаем два набора измерений: с числом клиентов 160 и 1600. Почему 160 клиентов? Ну просто потому, что ранее у PG при таких условиях мы наблюдали пик производительности.
Для PG особой разницы для двух измерений не видно, разве что большее количество соединений требует больше памяти, но это в измерениях не фигурирует. В PG практикуется использование различных прокси-приложений, играющих роль "connection pool", как минимум для экономии памяти.
В Соколе же большее количество соединений дает бОльшую отдачу от системы.
Причины:
1. Большое число параллельных активных соединений способствует более эффективному GROUP COMMIT, цена синхронизации отдельной транзакции падает.
2. При большем количестве соединений поддерживается постоянная нагрузка на ЦПУ - пока одни потоки ожидают подтверждения коммита, другие работают.
3. Фрагментация памяти между конкурирующим соединениями исключается за счет предварительной оценки необходимых ресурсов для исполнения запроса и атомарного запроса их целиком у системы.
4. Ресурсные затраты для неактивного соединения минимизированы, все ресурсы освобождаются.
Что можно на основе этого сказать?
1. Использование промежуточного приложения-мультиплексора соединений (он же "connection pool") - это часто вынужденная мера для компенсации архитектурных особенностей в существующей системе.
2. Мультиплексор соединений может быть даже вреден и может препятствовать эффективной работе СУБД, которая хорошо работает с большим количество соединений.
3. Сокол использует модель "coroutine per connection" и более того, неактивное соединение переходит в бесстековое состояние. Неактивное соединение не требует каких-либо значительных ресурсов. Можно сказать, что сам Сокол является отличным мультиплексором соединений.
Уточнение:
Термин "connection pool" может быть использован в разных смыслах. Здесь мы рассматривали его именно как мультиплексор соединений к СУБД, когда количество логических подключений от пользователя больше, чем число возможных подключений, которое обеспечивает СУБД.
Другое дело когда "connection pool" создается с целью уменьшения времени установления каждого нового соединения. Такая практика имеет право на жизнь и ее не будем оспаривать.
13February 25, 2025 2K 37 4
