Birikmalar va latency pullari

Birikmalar va latency pullari

1) Pullar nima uchun kerak?

• Tayyor konnektlarni qayta ishlatish (keep-alive) → TTFB ostida.
• Parallellikni nazorat qilish va retray ko’chkisi o’rniga backpressure berish.
• p95/p99 quyruqlarini toʻgʻri oʻlcham va taymaut hisobiga kamaytirish.

Asosiy xavflar: hovuzda kutish navbati, head-of-line blocking, konnektlar uchun kontenshen va retray bo’roni.

2) Matematika bazasi: pulning o’lchamini qanday hisoblash kerak

• ’λ’ - soʻrovlarning oʻrtacha oqimi (RPS).
• ’W’ - so’rov uchun ulanishning o’rtacha bandligi (service time, shu jumladan tarmoq latentligi va masofaviy servis ishi).
• Pulning eng kichik o’lchami:’N _ min ≈ λ × W’.
• O’zgarishlar uchun zaxirani qo’shing va p99: headroom 20-50%.
• Misol: 300 RPS, o’rtacha hold-time 40 ms →’N _ min = 300 × 0. 04 = 12`. 50% → 18 ta konnekt zaxirali.

Agar quyruqlar katta bo’lsa: kritik yo’llar uchun’W _ p95’yoki’W _ p99’ni hisobga oling - pullar o’sadi.

3) Loyihalashtirishning umumiy prinsiplari

1. Qisqa maʼlumot yoʻli: reuse (keep-alive, HTTP/2/3 multiplekslash).
2. Parallellikni cheklash: tezda (429/503) rad etish, orqa tomonni qovurishdan yaxshiroqdir.
3. Taymautlar> retrajlar: kichik taymautlar va noyob retrajlarni jitter bilan qoʻying.
4. Mijozning navbati serverdan qisqaroq (tezkor fail-fast).
5. Backpressure: pulni toʻldirganda - darhol NACK/xato/kolbek «keyinroq».
6. Maqsadlar bo’yicha pullarni izolyatsiya qilish: DB, kesh, tashqi PSP - o’z limitlari.

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

HTTP/1. 1: konnektga bir vaqtning o’zida bitta so’rov (amalda); Xost uchun bir nechta ulanishli hovuz kerak.
HTTP/2: bitta TCPda oqimlarni multiplekslash; konnektlar kamroq, lekin paketlar yo’qolganda TCPda HOL-blocking mumkin.
HTTP/3 (QUIC): UDP ustidagi oqim mustaqilligi - kamroq HOL muammolari, tezroq birinchi baytlar.

• keep-alive timeout 30-90s (profil bo’yicha), konnektga so’rovlar limiti (graceful recycle).
• Vorker boshlanganda preconnect (preconnect).
• HTTP/2 maksimal oqimini cheklash (masalan, 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) DB pullari: PgBouncer, HikariCP, drayverlar

Maqsad - raqobatbardosh tranzaksiyalarni cheklash va konnektni qisqa muddatda ushlab turish.

5. 1 PgBouncer (PostgreSQL)

Rejimlar:’session ’/’ transaction ’/’ statement’. API uchun - koʻproq transaction.
Muhim parametrlar:’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)

Kichik, tezkor konnektlar, qattiq taymautlar.

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’ yuz millisekund, soniya emas.
• leak detection.

5. 3 Go/Node/Python - misollar

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) Kutish navbatlari va tail-latency

• Pool’λ × W’→ dan kichikroq.
• Yuklamaning notekisligi (bursts) bufer va limitsiz.
• Uzoq so’rovlar HOLni yaratadi.

• Pullarni soʻrov turlariga (tez/sekin) ajrating.
• Connect kutish vaqtini (client-side) kiriting. Agar muddati tugasa - tezkor NACK.
• Yo’nalishlarda Outlier detection va circuit-breaking (Envoy, HAProxy).
• «Og’ir» yo’nalishlarga kvotalar, hisobotlar/eksport uchun alohida pullar.

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

7) Taymautlar va retrajlar (to’g "ri tartib)

1. Connect timeout (qisqa: DC ichida 50-250 ms).
2. TLS handshake timeout (500–1000 ms вне DC).
3. Request/Read timeout (yo’nalishning SLOga yaqinroq).
4. Retry: ko’pi bilan 1 marta, faqat idempotent usullar uchun; jitter + backoff.
5. Budget retraida: global limit RPS foizida (masalan, 10% ≤).

8) Keep-alive, Nagle, protokollar

Kichik xabarli RPC uchun Nagle (TCP_NODELAY) ni oʻchiring.
HTTP keep-alive’ni iloji boricha yoqing.
TIME_WAIT kuzating - tune’reuse ’/’ recycle’faqat oqibatlarini tushunsangiz; yaxshiroq - yadro tyuningi emas, balki konnektlarning reuse.
TLS: session resumption va ALPN’dan foydalaning.

9) OS/Kernel tyuning (ehtiyotkorlik bilan)

`net. core. somaxconn`, `net. ipv4. ip_local_port_range`, `net. ipv4. tcp_fin_timeout`.
Deskriptorlar:’nofile’≥ 64k proxy jarayoniga.
IRQ, GRO/LRO balansi - trafikning profili bo’yicha.
Ustuvorlik - profillash; metriksiz tyuning ko’pincha zararli.

10) Kuzatish darajasi: nimani o’lchash kerak

Pool utilization: band/hammasi, p50/p95 connect kutish.
In-flight so’rovlari va ularning hold-time (yo’nalishlar bo’yicha kesishlar).
Error budget retrayev: takrorlash ulushi.
Connection churn: sekundiga yaratish/yopish.
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) Keys-retseptlar

11. 1 API-shlyuz → backend

HTTP/2’max _ concurrent _ streams = 200’.
Shlyuz uzeliga xizmat ko’rsatish uchun 20-40 konnektli hovuz.
Taymautlar: connect 100ms, per-try 300-500ms, umumiy 1-2s, 1 retry jitter bilan.

11. 2 Xizmat → PgBouncer orqali PostgreSQL

’pool _ mode = transaction’,’default _ pool _ size’formula (RPS × W × 1. 3).
’connectionTimeout ≤ 250ms’ ilovasida, qisqa tranzaksiyalar (<100ms).
Og’ir hisobot so’rovlari - alohida pul/nusxa.

11. 3 gRPC ichki

Maqsadli xostga bitta kanal (HTTP/2), oqim limiti 100-200.
Yo’nalishning SLO bo’yicha RPC uchun deadline, faqat idempotent.
Uzun RPC va hold-time metrikasi uchun treys sampling.

12) Joriy etish chek-varaqasi (0-30 kun)

0-7 kun

Asosiy yo’nalishlar/mijozlarda’W’(hold-time) ni o’lchang.
’N _ min = λ × W’ hisoblang va 30-50% headroom qoʻshing.
keep-alive va qisqa kutish vaqtlarini yoqing.

8-20 kun

Pullarni ajrating (tezkor/sekin/tashqi).
circuit-breakers va budgets retraylarni kiriting.
Dashbordlarni qoʻshing: pool wait p95, reuse ratio, in-flight.

21-30 kun

Burstlar bilan yuk tashlash, «orqa tomonning tushishi» bo’yicha xaos-test.
Dumlar bo’yicha optimallashtirish: og’ir yo’nalishlarni izolyatsiya qilish, mahalliy keshlar.
Formulalar va limitlarni runbook’ax’da hujjatlashtiring.

13) Anti-patternlar

Pulning oʻlchami va headroom yoʻqligi.
Konnektni kutishning katta taymautlari → tezda nosozliklar o’rniga uzun dumlar.
Jittersiz va idempotentsiz retrajlar ko’p → bo’ron.
Barcha turdagi soʻrovlar uchun bitta umumiy hovuz.
Uzoq tranzaktsiyalar (DB) → starvation qolganlarini ushlab turadi.
Oʻchirilgan keep-alive yoki juda kichik idle → churn limitlari va TTFB oʻsishi.

14) Etuklik metrikasi

Pool wait p95 proda <10% umumiy p95 yo’nalish.
Reuse ratio (ichki HTTP uchun> 90%; tashqi HTTP uchun> 80%).
DB txn time p95 < 100–200 ms; uzoq tranzaksiyalar ulushi <1%.
Retry rate <5% (va ≤ budget), timeouts tufayli xatolar barqaror va oldindan aytib bo’ladi.
Barcha tanqidiy mijozlar uchun pulning hujjatlashtirilgan hisob-kitobi.

15) Xulosa

Samarali connection pooling - bu navbat muhandisligi + taymaut intizomi. ’W’ ni o’lchang,’λ’× W’ni zaxirali hisoblang, keep-alive/HTTP2 + ni yoqing, sekin yo’llarni ajrating, qisqa vaqtlarni va minimal retrajlarni jitter bilan saqlang. «pool wait vs latency» va circuit-breakers ko’rinishini qo’shing - va siz past TTFB, nazorat qilinadigan p99 dumi va ortiqcha isinmasdan portlashga chidamli bo’lasiz.