Bağlantı hovuzları və latency

Bağlantı hovuzları və latency

1) Niyə pullar lazımdır

• Hazır konnektləri (keep-alive) → TTFB altında yenidən istifadə edin.
• Paralelliyə nəzarət edin və retrajların uçqunu əvəzinə backpressure verin.
• Düzgün ölçü və vaxt ilə p95/p99 quyruqlarını azaltın.

Əsas risklər: hovuzda gözləmə növbələri, baş-line blocking, konnektlər və fırtına retrains üçün kontenşen.

2) Riyaziyyat bazası: hovuz ölçüsünü necə hesablamaq olar

• 'λ' - orta sorğu axını (RPS).
• 'W' - sorğuya qoşulmanın orta məşğulluğu (şəbəkə gizliliyi və uzaqdan xidmət də daxil olmaqla service time).
• Minimum hovuz ölçüsü: 'N _ min ≈ λ × W'.
• Varyasyonlar və p99 altında ehtiyat əlavə edin: 20-50% headroom.
• Nümunə: 300 RPS, orta hold-time 40 ms → 'N _ min = 300 × 0. 04 = 12`. 50% → 18 konnekt ehtiyatı ilə.

Quyruqlar böyükdürsə: kritik yollar üçün 'W _ p95' və ya 'W _ p99' nəzərə alın - hovuzlar böyüyür.

3) Ümumi dizayn prinsipləri

1. Qısa məlumat yolu: reuse (keep-alive, HTTP/2/3 multiplexing).
2. Paralelliyin məhdudlaşdırılması: tez bir zamanda (429/503) qovurmaqdan imtina etmək daha yaxşıdır.
3. Taymautlar> retrasiyalar: kiçik taymautları və nadir retrasları jitterlə nümayiş etdirin.
4. Müştərinin növbələri serverdən daha qısadır (sürətli fail-fast).
5. Backpressure: hovuz dolu olduqda - dərhal NACK/səhv/kollbek «sonra».
6. Məqsədlərə görə hovuzların izolyasiyası: DB, cache, xarici PSP - öz limitləri.

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

HTTP/1. 1: eyni zamanda bir konnekt sorğusu (praktiki olaraq); host üçün bir neçə bağlantı ilə hovuz lazımdır.
HTTP/2: bir TCP-də axınların multipleksləşdirilməsi; daha az bağlayıcı, lakin paket itkisi ilə TCP-də HOL-blocking mümkündür.
HTTP/3 (QUIC): UDP üzərindən axın müstəqilliyi - daha az HOL problemləri, daha sürətli ilk baytlar.

• keep-alive timeout 30-90s (profil üzrə), connect sorğu limiti (graceful recycle).
• Worker başlanğıc preconnect.
• Maksimum HTTP/2 axınının məhdudlaşdırılması (məsələn, 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) BD hovuzları: PgBouncer, HikariCP, sürücülər

Məqsəd rəqabətli əməliyyatları məhdudlaşdırmaq və konektin qısa tutulmasını saxlamaqdır.

5. 1 PgBouncer (PostgreSQL)

Rejimlər: 'session '/' transaction '/' statement'. API üçün - daha tez-tez transaction.
Mühüm parametrlər: '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)

Kiçik, sürətli konnektlər, sərt vaxtlar.

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' yüzlərlə millisaniyə, saniyə deyil.
• leak detection daxil edin.

5. 3 Go/Node/Python - nümunələr

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) Gözləmə növbələri və tail-latency

• Hovuz 'λ × W' → dən kiçikdir.
• Tampon və limitsiz yük (bursts).
• Uzun sorğular konnekt tutur və HOL yaradır.

• Hovuzları sorğu növlərinə görə bölün (sürətli/yavaş).
• connect (client-side) gözləmə müddətini tətbiq edin. Əgər vaxtı keçibsə - sürətli NACK.
• Outlier detection və circuit-breaking marşrutları (Envoy, HAProxy).
• «Ağır» marşrutlar üçün kvotalar, hesabatlar/ixraclar üçün ayrıca hovuz.

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

7) Vaxtlar və retrajlar (düzgün sifariş)

1. Connect timeout (qısa: DC daxilində 50-250 ms).
2. TLS handshake timeout (500–1000 ms вне DC).
3. Request/Read timeout (SLO marşrutu yaxın).
4. Retry: maksimum 1 dəfə, yalnız idempotent üsulları üçün; jitter + backoff.
5. Retrajda Budget: RPS faizində qlobal limit (məsələn, ≤ 10%).

8) Keep-alive, Nagle, protokollar

Kiçik mesajlarla RPC üçün Nagle (TCP_NODELAY) off.
HTTP keep-alive 'i mümkün olan hər yerdə açın.
TIME_WAIT - tune 'reuse '/' recycle' yalnız nəticələrini başa düşsəniz; daha yaxşı - reuse bağlantı deyil, tuning nüvə.
TLS: session resumption və ALPN istifadə edin.

9) OS/Kernel sazlama (ehtiyatla)

`net. core. somaxconn`, `net. ipv4. ip_local_port_range`, `net. ipv4. tcp_fin_timeout`.
Deskriptorlar: 'nofile' ≥ 64k proxy prosesinə.
Balans IRQ, GRO/LRO - trafik profilinə görə.
Prioritet - profil; metrik olmadan tuning tez-tez zərər verir.

10) Müşahidə: nə ölçmək lazımdır

Pool utilization: məşğul/ümumi, p50/p95 connect gözləmək.
In-flight sorğular və onların hold-time (marşrutlar üzrə kəsilir).
Error budget retrains: təkrar payı.
Connection churn: saniyədə yaratmaq/bağlamaq.
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) Case reseptləri

11. 1 API-şlyuz → backend

HTTP/2, 'max _ concurrent _ streams = 200'.
Şlüz qovşağına xidmət üçün 20-40 konnekt hovuzu.
Zaman: connect 100ms, per-try 300-500ms, ümumi 1-2s, 1 retry jitter ilə.

11. 2 Xidmət → PgBouncer vasitəsilə PostgreSQL

'pool _ mode = transaction', 'default _ pool _ size' düsturu (RPS × W × 1. 3).
'connectionTimeout ≤ 250ms' tətbiqində, qısa əməliyyatlar (<100ms).
Ağır hesabat sorğuları - ayrı hovuz/replika.

11. 3 gRPC daxili

100-200 axın limiti ilə hədəf host üçün bir kanal (HTTP/2).
SLO marşrutu üzrə RPC Deadline, retray yalnız idempotent.
uzun RPC və hold-time metrik üçün treys sampling.

12) Giriş çek siyahısı (0-30 gün)

0-7 gün

Əsas marşrutlarda/müştərilərdə 'W' (hold-time) ölçün.
'N _ min = λ × W' hesablayın və 30-50% headroom əlavə edin.
keep-alive və qısa connect gözləmə vaxtlarını daxil edin.

8-20 gün

Hovuzları bölün (sürətli/yavaş/xarici).
circuit-breakers və budgets retrains daxil edin.
Dashboard əlavə edin: pool wait p95, reuse ratio, in-flight.

21-30 gün

Burstlar ilə yükləmə, xaos testi «arxa tərəfin düşməsi».
Quyruqlarda optimallaşdırma: ağır marşrutların izolyasiyası, yerli keşlər.
Formulları və limitləri runbook 'ax-da sənədləşdirin.

13) Anti-nümunələr

Hovuzun ölçüsü «təsadüfi» və headroom yoxdur.
Sürətli uğursuzluqlar əvəzinə → uzun quyruqların böyük gözləmə müddəti.
Jitter və idempotent olmadan çox retrains → fırtına.
Bütün növ sorğular üçün bir ümumi hovuz.
Uzun əməliyyatlar bağlayıcı saxlayır (DB) → starvation qalanları.
Off keep-alive və ya çox kiçik limitləri idle → churn və TTFB artım.

14) Yetkinlik metrikası

Pool wait p95 <10% ümumi p95 marşrutu.
Reuse ratio (> 90% daxili HTTP üçün;> 80% xarici üçün).
DB txn time p95 < 100–200 ms; uzun əməliyyatların payı <1%.
Retry rate <5% (və ≤ budget), timeouts səbəbiylə səhvlər sabit və proqnozlaşdırıla bilər.
Bütün kritik müştərilər üçün sənədli hovuz hesabı.

15) Nəticə

Effektiv connection pooling növbə mühəndisliyi + taymaut intizamıdır. 'W' ölçün, 'λ × W' hovuzunu ehtiyat ilə hesablayın, keep-alive/HTTP2 + aktivləşdirin, yavaş yolları ayırın, qısa vaxtları və minimum retrajları jitter ilə saxlayın. «pool wait vs latency» və circuit-breakers müşahidə əlavə edin - və siz aşağı TTFB, nəzarət p99 quyruq və həddindən artıq istiləşmədən partlayışlara qarşı müqavimət alacaqsınız.