Что такое connection pooling для БД и HTTP?

#Зачем нужен пул

#Пул соединений ADO.NET

Host=db;Database=shop;Username=app;Password=***;
Pooling=true;                 # по умолчанию true
Minimum Pool Size=0;          # держать открытыми минимум N
Maximum Pool Size=100;        # по умолчанию 100
Connection Idle Lifetime=300; # закрывать простаивающие (Npgsql)
Timeout=15;                   # ожидание соединения из пула / установки
Command Timeout=30;           # таймаут команды

Важно:

• Пул — на строку подключения (и на процесс). Разные строки (даже порядок параметров, другой пароль, другая БД) → разные пулы.
• Dispose обязателен — using/await using. Без него соединение вернётся в пул только после финализации — практически утечка.
• EF Core сам открывает и закрывает соединение на время запроса/SaveChanges (или на время транзакции) — пулом пользуется автоматически.

#Диагностика исчерпания

public async Task<int> CountAsync()
{
    var conn = new NpgsqlConnection(_cs);          // нет using!
    await conn.OpenAsync();
    return (int)(long)(await new NpgsqlCommand("SELECT count(*) FROM orders", conn).ExecuteScalarAsync())!;
}   // соединение не возвращено в пул

• Счётчики: Npgsql/SqlClient публикуют метрики (db.client.connections.usage, idle/used, pending requests) через OpenTelemetry.
• На стороне БД: SELECT state, count(*) FROM pg_stat_activity GROUP BY state; — много idle in transaction? Долгие транзакции держат соединения.
• Долгие запросы под нагрузкой: каждый держит соединение дольше → при 100 одновременных медленных запросах пул исчерпан.

#Сколько соединений нужно

• Больше соединений ≠ быстрее: БД эффективна при числе активных соединений порядка «ядра × 2–4». Сотни активных соединений конкурируют за CPU, память и блокировки.
• PgBouncer / Odyssey / RDS Proxy / Azure PgBouncer: тысячи клиентских соединений → десятки серверных. Режим transaction pooling несовместим с session-состоянием (prepared statements на уровне сессии, SET, advisory locks уровня сессии) — Npgsql: No Reset On Close=true, осторожно с Max Auto Prepare.
• Multiplexing Npgsql: несколько команд по одному соединению — меньше соединений при высокой нагрузке.

#HTTP connection pooling

builder.Services.AddHttpClient<ICatalogClient, CatalogClient>(c =>
{
    c.BaseAddress = new Uri("https://catalog.internal");
    c.Timeout = TimeSpan.FromSeconds(10);
})
.ConfigurePrimaryHttpMessageHandler(() => new SocketsHttpHandler
{
    PooledConnectionLifetime = TimeSpan.FromMinutes(2),       // пересоздавать соединения → подхватывать изменения DNS
    PooledConnectionIdleTimeout = TimeSpan.FromMinutes(1),
    MaxConnectionsPerServer = 100                              // лимит одновременных соединений к хосту (HTTP/1.1)
})
.AddStandardResilienceHandler();

public sealed class CatalogClient(HttpClient http) : ICatalogClient    // typed client: HttpClient создаётся фабрикой
{
    public Task<ProductDto?> GetAsync(int id, CancellationToken ct) => http.GetFromJsonAsync<ProductDto>($"/products/{id}", ct);
}

private static readonly HttpClient Http = new(new SocketsHttpHandler { PooledConnectionLifetime = TimeSpan.FromMinutes(2) });

IHttpClientFactory кэширует и переиспользует HttpMessageHandler-ы (с пулами соединений), периодически ротируя их (HandlerLifetime, по умолчанию 2 минуты), а сами HttpClient — дешёвые обёртки, которые можно создавать часто.

#Другие пулы

#Вопросы на засыпку

#Итог

Пул соединений убирает дорогую установку соединения из каждого запроса. Для БД — всегда Dispose, короткие транзакции, разумный Max Pool Size с учётом числа экземпляров и пулер (PgBouncer) при масштабировании. Для HTTP — IHttpClientFactory или один клиент с PooledConnectionLifetime, но никогда не new HttpClient() на запрос.