Pools de connexions et latitude

Pools de composés et latitude

1) Pourquoi les pools sont-ils nécessaires

• L'utilisation des connexions prêtes à l'emploi (keep-alive) → inférieure à la TTFB.
• Contrôler le parallélisme et donner une backpressure au lieu d'une avalanche de retraits.
• Réduire les queues p95/p99 en raison de la taille et du délai corrects.

Les principaux risques sont les files d'attente dans le pool, le blocking tête de ligne, le contour derrière les connexions et la tempête de rétrécissements.

2) Base de mathématiques : Comment compter la taille du pool

• « λ » est le flux moyen de requêtes (RPS).
• « W » est l'occupation moyenne de la connexion à la demande (service time, y compris la latence réseau et le fonctionnement du service à distance).
• La taille minimale du pool est 'N _ min ≈ λ × W'.
• Ajoutez le stock sous variations et p99 : headroom 20-50 %.
• Exemple : 300 RPS, moyenne hold-time 40 ms → 'N _ min = 300 × 0. 04 = 12`. Avec une réserve de 50 % → 18 connexions.

Si les queues sont grandes : tenez compte de 'W _ p95' ou 'W _ p99' pour les voies critiques - les pools grandissent.

3) Principes généraux de conception

1. Chemin de données court : reuse (keep-alive, multiplexage HTTP/2/3).
2. Limitation du parallélisme : mieux vaut refuser rapidement (429/503) que d'allumer un backend.
3. Timeouts> retraits : exposez les petits timeouts et les rares retraits avec jitter.
4. Les files d'attente du client sont plus courtes que celles du serveur (fail-fast rapide).
5. Backpressure : lorsque le pool est plein - immédiatement NACK/bug/collback « plus tard ».
6. Isolation des pools par objectifs : DB, cache, PSP externes - leurs limites.

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

HTTP/1. 1 : une demande de connecteur en même temps (pratiquement) ; Il faut un pool avec plusieurs connexions par hôte.
HTTP/2 : multiplexage des flux dans un seul TCP ; moins de connexions, mais HOL-blocking est possible sur TCP lorsque des paquets sont perdus.
HTTP/3 (QUIC) : indépendance en streaming au-dessus de l'UDP - moins de problèmes HOL, plus rapides que les premiers octets.

• keep-alive timeout 30-90s (par profil), limite des demandes de connexion (graceful recycle).
• Préchauffage (preconnect) au démarrage du worker.
• Limiter les flux maximum par HTTP/2 (par exemple 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) Pools OBD : PgBouncer, HikariCP, pilotes

L'objectif est de limiter les transactions concurrentielles et de maintenir les détentions courtes du connecteur.

5. 1 PgBouncer (PostgreSQL)

Modes : 'session '/' transaction '/' statement'. Pour l'API - plus souvent transaction.
Paramètres importants : '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)

Petites connexions rapides, temps durs.

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

• `maximumPoolSize ≈ RPS × W × headroom`.
• 'ConnectionTimeout 'des centaines de millisecondes, pas une seconde.
• Activez leak detection.

5. 3 Go/Node/Python - exemples

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) Files d'attente et tail-latency

• Le pool est plus petit que 'λ × W' → la file d'attente du connecteur augmente.
• Irrégularités de charge (bursts) sans tampon ni limites.
• Les longues demandes sont occupées par le connecteur et créent le HOL.

• Divisez les pools par type de requête (rapide/lente).
• Mettez en place le délai d'attente du connecteur (client-side). Si vous avez expiré, un NACK rapide.
• Outlier detection et circuit-breaking sur les itinéraires (Envoy, HAProxy).
• Quotas pour les itinéraires « lourds », un pool distinct pour les déclarations/exportations.

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

7) Timouts et Retrai (ordre correct)

1. Connect timeout (court : 50-250 ms à l'intérieur de DC).
2. TLS handshake timeout (500–1000 ms вне DC).
3. Demande/Lecture timeout (plus proche de la route SLO).
4. Retry : 1 fois maximum, uniquement pour les méthodes idempotentes ; jitter + backoff.
5. Budget sur les retraits : limite globale en pourcentage du RPS (par exemple, 10 % ≤).

8) Keep-alive, Nagle, protocoles

Désactivez Nagle (TCP_NODELAY) pour les petits messages RPC.
Allumez HTTP keep-alive partout où c'est possible.
Regardez le TIME_WAIT - tune 'reuse '/' recycle' seulement si vous comprenez les conséquences ; mieux vaut reuse connections plutôt que tuning noyau.
TLS : utilisez la résolution de session et l'ALPN.

9) OS/Kernel tuning (avec soin)

`net. core. somaxconn`, `net. ipv4. ip_local_port_range`, `net. ipv4. tcp_fin_timeout`.
Descripteurs : 'nofile' ≥ 64k par processus proxy.
Équilibre IRQ, GRO/LRO - par profil de trafic.
La priorité est de profiler ; le tuning sans métriques fait souvent mal.

10) Observabilité : que mesurer

Utilisation du pool : Occupé/Total, p50/p95 attentes du connecteur.
Demandes in-flight et leur hold-time (tranches par itinéraire).
Error budget rétrogrades : proportion de répétitions.
Connection churn : création/fermeture par seconde.
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) Recettes de cas

11. 1 passerelle API → backend

HTTP/2 aux backends, 'max _ concours _ streams = 200'.
Un pool de 20 à 40 connexions par nœud de passerelle.
Temporisation : connect 100ms, per-try 300-500ms, général 1-2s, 1 retry avec gitter.

11. 2 Service → PostgreSQL via PgBouncer

'pool _ mode = transaction', 'default _ pool _ size' selon la formule (RPS × W × 1. 3).
Dans l'application « connectionTimeout≤250ms », transactions courtes (<100ms).
Les demandes de rapports lourds sont un pool/réplique distinct.

11. 3 gRPC interne

Un canal (HTTP/2) par hôte cible avec une limite de flux de 100 à 200.
Deadline sur RPC sur la route SLO, retraits seulement idempotent.
Sampling trails pour RPC longs et métriques hold-time.

12) Chèque de mise en œuvre (0-30 jours)

0-7 jours

Mesurez 'W' (hold-time) sur les itinéraires/clients clés.
Calculez 'N _ min = λ × W' et ajoutez 30-50 % de headroom.
Activez keep-alive et les brefs temps d'attente du connecteur.

8-20 jours

Séparez les pools (rapides/lents/externes).
Entrez les breakers de circuit et les retraits de budget.
Ajoutez des dashboards : pool wait p95, reuse ratio, in-flight.

21-30 jours

Essais de charge avec des bourrasques, test de chaos « chute de backend ».
Optimisation par queue : isolation des routes lourdes, caches locaux.
Documentez les formules et les limites dans runbook 'ax.

13) Anti-modèles

Taille du pool « au hasard » et absence de headroom.
Les longs délais d'attente du connecteur → les longues queues au lieu des échecs rapides.
Beaucoup de rétrogrades sans jitter et sans idempotence → tempête.
Un pool commun pour tous les types de requêtes.
Les transactions à long terme sont détenues par le connecteur (DB) → la starvation des autres.
Désactivé keep-alive ou trop petites limites idle → churn et croissance TTFB.

14) Métriques de maturité

Pool wait p95 en vente <10 % de l'itinéraire total p95.
Reuse ratio (> 90 % pour les HTTP internes ;> 80 % pour les HTTP externes).
DB txn time p95 < 100–200 ms; proportion de transactions longues <1 %.
Taux de retard <5 % (et ≤ budget), les erreurs dues aux timeouts sont stables et prévisibles.
Calcul documenté du pool pour tous les clients critiques.

15) Conclusion

L'efficacité de la connection pooling est l'ingénierie des files d'attente + la discipline des temporisateurs. Mesurez 'W', calculez le pool 'λ × W' avec la marge, allumez keep-alive/HTTP2 +, séparez les voies lentes, gardez les délais courts et les retraits minimaux avec le gitter. Ajoutez l'observabilité « pool wait vs latency » et les circuits-breakers - et vous obtiendrez un faible TTFB, une queue contrôlée p99 et une résistance aux surchauffes sans surchauffe des backends.