Pool di connessioni e latency

Pool di connessioni e latency

1) Perché i pool sono necessari

• Riutilizza connettori finiti (keep-alive) sotto TTFB.
• Controllare il parallelismo e dare backpressure invece di una valanga di retrai.
• Riduce le code p95/p99 grazie alle giuste dimensioni e timeout.

Rischi chiave: code di attesa nel pool, head-of-line blocking, contensivi per i connettori e la tempesta di retrai.

2) Base matematica: come contare la dimensione del pool

• 'bit '- Flusso di query medio (RPS).
• «W» è l'occupazione media della connessione alla richiesta (service time, inclusa la latitanza di rete e il funzionamento del servizio remoto).
• La dimensione minima del pool è «N _ min ≈ x W».
• Aggiungi scorte per variazioni e p99: headroom 20-50%.
• Esempio: 300 RPS, media hold-time 40 ms → N _ min = 300 x 0. 04 = 12`. Con una riserva del 50 → di 18 connettori.

Se le code sono grandi, considerate W _ p95 o W _ p99 per i percorsi critici, i pool crescono.

3) Principi generali di progettazione

1. Il percorso dei dati è reuse (keep-alive, HTTP/2/3 multiplex).
2. Limitazione del parallelismo: meglio guastare rapidamente (429/503) che cuocere backend.
3. Timeout> retrai: mostra piccoli timeout e rari retrai con jitter.
4. Le code del client sono più corte rispetto al server (veloce fail-fast).
5. Backpressure: quando il pool è pieno, immediatamente NACK/Errore/Collaudo successivo.
6. Isolare i pool in base agli obiettivi: DB, cash, PSP esterni: i propri limiti.

4) HTTP/1. 1 vs HTTP/2/3, keep-alive

HTTP/1. 1: una richiesta di connettivo simultaneamente (praticamente); serve un pool con più connettori per host.
HTTP/2: multiplexing dei flussi in un singolo TCP; meno connettori, ma è possibile HOL-blocking su TCP quando si perdono i pacchetti.
HTTP/3 (QUIC) - L'indipendenza in streaming sopra UDP è minore di problemi HOL, più veloce dei primi byte.

• keep-alive timeout 30-90s (profilo), limite di richieste di connect (graceful recycle).
• Precursore (preconnect) all'avvio del worker.
• Limita il flusso massimo a HTTP/2 (ad esempio 100-200).

nginx upstream backend {
server app-1:8080;
server app-2:8080;
keepalive 512;
keepalive_requests 1000;
keepalive_timeout 60s;
}
proxy_http_version 1. 1;
proxy_set_header Connection "";

yaml http2_protocol_options:
max_concurrent_streams: 200 common_http_protocol_options:
idle_timeout: 60s max_connection_duration: 3600s

5) Pool database: PgBouncer, HikariCP, driver

L'obiettivo è quello di limitare le transazioni competitive e mantenere un connettivo breve.

5. 1 PgBouncer (PostgreSQL)

Modalità: sessione/transaction/statement. Per l'API, è più frequente la trasmissione.
Opzioni importanti: 'pool _ size', 'min _ pool _ size', 'reserve _ pool _ size', 'server _ idle _ timeout', 'query _ wait _ timeout'.

ini
[databases]
appdb = host=pg-primary port=5432 dbname=appdb

[pgbouncer]
pool_mode = transaction max_client_conn = 5000 default_pool_size = 100 min_pool_size = 20 reserve_pool_size = 20 query_wait_timeout = 500ms server_idle_timeout = 60 server_reset_query = DISCARD ALL

5. 2 HikariCP (Java)

Connettori piccoli, veloci, timeout rigidi.

properties dataSourceClassName=org. postgresql. ds. PGSimpleDataSource maximumPoolSize=30 minimumIdle=5 connectionTimeout=250 validationTimeout=200 idleTimeout=30000 maxLifetime=1800000 leakDetectionThreshold=5000

• `maximumPoolSize ≈ RPS × W × headroom`.
• 100 millisecondi, non secondi.
• Attivare leak detection.

5. 3 Go/Node/Python - esempi

go tr:= &http. Transport{
MaxIdleConns:    512,
MaxIdleConnsPerHost: 128,
IdleConnTimeout:   60 time. Second,
TLSHandshakeTimeout: 2 time. Second,
}
c:= &http. Client{
Transport: tr,
Timeout:  2 time. Second ,//general
}

js const http = require('http');
const agent = new http. Agent({ keepAlive: true, maxSockets: 200, maxFreeSockets: 64, timeout: 60000 });

python engine = create_engine(
url, pool_size=30, max_overflow=10, pool_recycle=1800, pool_pre_ping=True, pool_timeout=0. 25
)

6) Code di attesa e tail-latency

• Il pool è più piccolo di «→ x W».
• Irregolarità di carico (bursts) senza buffer o limiti.
• Le lunghe richieste occupano il connettivo e creano HOL.

• Separare i pool per tipo di query (rapido/lento).
• Implementare il timeout di attesa del connect (client-side). Se scaduto, NACK veloce.
• Outlier detection e circuito-breaking sui percorsi (Avvoy, HAProxy).
• Quote di percorsi pesanti, pool separato per report/esportazioni.

yaml circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 200 max_pending_requests: 100 max_requests: 1000 max_retries: 2

7) Timeout e retrai (ordine corretto)

1. Connect timeout (breve: 50-250 ms all'interno del DC).
2. TLS handshake timeout (500–1000 ms вне DC).
3. Richiest/Read timeout (più vicino al percorso SLO).
4. Retry: massimo 1 volta, solo per metodi Idempotent jitter + backoff.
5. Budget su retrai: limite globale percentuale di RPS (ad esempio 10%).

8) Keep-alive, Nagle, protocolli

Disattiva Nagle (TCP _ NODELAY) per RPC con messaggi di piccole dimensioni.
Attivare HTTP keep-alive ovunque possibile.
Tieni d'occhio TIME _ WAIT - tune «reuse »/« recycle» solo se capisci le conseguenze; meglio il reuse dei connettori, non il tuning del nucleo.
TLS - Utilizzare la sessione Respumption e ALPN.

9) OS/Kernel tuning (con cautela)

`net. core. somaxconn`, `net. ipv4. ip_local_port_range`, `net. ipv4. tcp_fin_timeout`.
Descrittori: 'nofile', 64k per il processo proxy.
Bilanciamento IRQ, GRO/LRO - profilo di traffico.
La priorità è profilare; il tuning senza metriche spesso fa male.

10) Osservabilità: cosa misurare

Pool utilization è occupato/totale, p50/p95 in attesa del connettivo.
In-flight le query e il relativo hold-time (tagli lungo i percorsi).
La percentuale di ripetizioni è «Errore budget».
Connection churn: creazione/chiusura al secondo.
TCP/TLS: SYN RTT, handshakes, session reuse.
Для БД: active connections, waiting, long transactions, locks.

Графики: «RPS vs pool wait», «hold-time distribution», «reuse ratio», «circuit trips».

11) Ricette case

11. 1 gateway API → backend

HTTP/2 alle backend, 'max _ concurrent _ streams = 200'.
Un pool di 20-40 connettori per il servizio sul nodo gateway.
Timeout: connect 100ms, per-try 300-500ms, totale 1-2s, 1 retry con jitter.

11. 2 Strumenti di attraverso il

«pool _ mode = communication», «default _ pool _ size» secondo la formula (RPS x W x 1. 3).
Nell'applicazione «connectionTimeout≤250ms», transazioni brevi (<100ms).
Query di report pesanti: pool/replica separato.

11. 3 gRPC interno

Un canale (HTTP/2) per host di destinazione con limite di flusso 100-200.
Deadline su RPC percorso SLO, retrai solo idempotent.
Sampling delle roulotte per RPC lunghe e metriche hold-time.

12) Assegno foglio di implementazione (0-30 giorni)

0-7 giorni

Misurare'W '(hold-time) su percorsi/client chiave.
Calcola «N _ min = © x W» e aggiungi il 30-50% di headroom.
Attivare keep-alive e brevi timeout di attesa del connettivo.

8-20 giorni

Separare i pool (veloci/lenti/esterni).
Digitare i circuiti-breakers e i retrai budgets.
Aggiungi i dashboard: pool wait p95, reuse ratio, in-flight.

21-30 giorni

Test di carico con le tempeste, test di caos «calo del backend».
Ottimizzazione di coda: isolamento dei percorsi pesanti, cache locale.
Documentare le formule e i limiti nel runbook 'ax.

13) Anti-pattern

Dimensioni del pool casuale e assenza di headroom.
I grandi timeout di attesa per il Connect sono molto lunghi, invece di guasti rapidi.
Un sacco di retroscena senza jitter e idampotenza.
Un pool condiviso per tutti i tipi di query.
Transazioni di lunga durata tengono il Connect (DB) a starvation del resto.
Keep-alive disattivato o limiti idle-churn troppo piccoli e altezza TTFB.

14) Metriche di maturità

Pool wait p95 in vendita <10% del percorso totale p95.
Reuse ratio (> 90% per HTTP interni;> 80% per gli esterni).
DB txn time p95 < 100–200 ms; Percentuale di transazioni lunghe <1%.
Retry rate <5% (e ≤ budget), gli errori a causa dei timeouts sono stabili e prevedibili.
Calcolo documentato del pool per tutti i clienti critici.

15) Conclusione

Connection pooling efficiente è l'ingegneria delle code + disciplina dei timeout. Misurare «W», calcolare il pool «© x W» con riserva, attivare keep-alive/HTTP2 +, separare i percorsi lenti, mantenere brevi timeout e minimi retrai con jitter. Aggiungi l'osservabilità «pool wite vs latency» e i circuiti-breakers - e ottieni un basso TTFB, una coda p99 controllata e la resistenza ai picchi senza surriscaldare i backend.