Қосылыстар мен latency пулдары

Қосылыстар мен latency пулдары

1) Пулдар не үшін қажет

• Дайын коннектілерді қайта пайдалану (keep-alive) → TTFB төмен.
• Параллелизмді бақылау және ретрайлардың көшкінінің орнына backpressure беру.
• p95/p99 қалдықтарын дұрыс өлшемдер мен таймауттар есебінен кішірейту.

Негізгі тәуекелдер: пулда күту кезегі, head-of-line blocking, коннектілер үшін контеншен және ретрайлардың дауылы.

2) Математика базасы: пулдың өлшемін қалай санау керек

• 'λ' - орташа сұрау ағыны (RPS).
• 'W' - сұрау салуға қосылыстың орташа бос еместігі (желілік жасырындылықты және қашықтағы сервистің жұмысын қоса алғанда service time).
• Пулдың ең кіші өлшемі: 'N _ min ≈ λ × W'.
• Вариация және p99 үшін қор қосыңыз: headroom 20-50%.
• Мысалы: 300 RPS, орташа hold-time 40 ms → 'N _ min = 300 × 0. 04 = 12`. 50% → 18 коннект қоры бар.

Егер қалдықтар үлкен болса: сыни жолдар үшін 'W _ p95' немесе 'W _ p99' ескеріңіз - пулдар өседі.

3) Жобалаудың жалпы қағидаттары

1. Деректердің қысқа жолы: reuse (keep-alive, HTTP/2/3 мультиплексиялау).
2. Параллелизмді шектеу: бэкендті қуырғаннан гөрі тез (429/503) бас тартқан жақсы.
3. Таймауттар> ретрайлер: шағын таймауттар мен сирек ретрайлерді джиттермен бірге қойыңыз.
4. Клиенттің кезегі серверге қарағанда қысқа (жылдам fail-fast).
5. Backpressure: пул толған кезде - дереу NACK/қате/colbek «кейінірек».
6. Пулдарды мақсаттар бойынша оқшаулау: DB, кэш, сыртқы PSP - өз лимиттері.

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

HTTP/1. 1: бір уақытта коннектке бір сұрау салу (іс жүзінде); хостқа бірнеше коннектілері бар пул қажет.
HTTP/2: ағындарды бір TCP-де мультиплексиялау; коннектілер аз, бірақ пакеттерді жоғалтқан кезде TCP-де HOL-blocking болуы мүмкін.
HTTP/3 (QUIC): UDP үстінен ағынды тәуелсіздік - HOL проблемаларынан аз, бірінші байттардан жылдам.

• keep-alive timeout 30-90s (бейін бойынша), коннектке сұрау лимиті (graceful recycle).
• Воркерді бастағанда алдын ала жылыту (preconnect).
• HTTP/2 ең көп ағындарды шектеу (мысалы, 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) Пулы БД: PgBouncer, HikariCP, драйверлер

Мақсаты - бәсекелестік транзакцияларды шектеу және коннектіні қысқа ұстап тұру.

5. 1 PgBouncer (PostgreSQL)

'session '/' transaction '/' statement' режимдері. API үшін - жиі transaction.
Маңызды параметрлер: '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)

Шағын, жылдам коннектілер, қатты таймауттар.

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' жүздеген миллисекунд, секунд емес.
• leak detection бағдарламасын қосыңыз.

5. 3 Go/Node/Python - мысалдар

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) Күту кезегі және tail-latency

• Пул 'λ × W' → дегеннен кішірек.
• Буферсіз және лимиттерсіз жүктеменің тегіс еместігі (bursts).
• Ұзақ сұраулар коннектіні қамтиды және HOL құрады.

• Пулдарды сұрау түрлері бойынша бөліңіз (жылдам/баяу).
• Коннектіні күту уақытын енгізіңіз (client-side). Егер мерзімі өтсе - жылдам NACK.
• Outlier detection және circuit-breaking бағыттарында (Envoy, HAProxy).
• «Ауыр» маршруттарға квоталар, есептер/экспорттар үшін жеке пул.

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

7) Таймауттар мен ретрациялар (дұрыс тәртіп)

1. Connect timeout (қысқа: DC ішінде 50-250 ms).
2. TLS handshake timeout (500–1000 ms вне DC).
3. Request/Read timeout (SLO бағытына жақын).
4. Retry: ең көп дегенде 1 рет, тек қана демпотенттік әдістер үшін; джиттер + backoff.
5. Ретрадағы Budget: RPS-тен пайызбен жаһандық лимит (мысалы, ≤ 10%).

8) Keep-alive, Nagle, хаттамалар

Шағын хабарлары бар RPC үшін Nagle (TCP_NODELAY) бағдарламасын өшіріңіз.
HTTP keep-alive мүмкіндігінше барлық жерде қосыңыз.
Тек салдарын түсінсеңіз ғана TIME_WAIT - tune 'reuse '/' recycle'; жақсы - ядроның тюнингі емес, коннектілердің reuse.
TLS: session resumption және ALPN пайдаланыңыз.

9) OS/Kernel тюнинг (сақтықпен)

`net. core. somaxconn`, `net. ipv4. ip_local_port_range`, `net. ipv4. tcp_fin_timeout`.
Дескрипторлар: 'nofile' ≥ 64k прокси процесіне.
IRQ, GRO/LRO теңгерімі - трафик бейіні бойынша.
Басымдығы - бейіндеу; метрикасыз тюнинг жиі зиян келтіреді.

10) Бақылау: не өлшеу керек

Pool utilization: бос емес/барлығы, p50/p95 коннектіні күту.
In-flight сұраулары және олардың hold-time (бағыттар бойынша кесінділер).
Error budget ретрайлары: қайталау үлесі.
Connection churn: секундына жасау/жабу.
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) Кейс-рецепттер

11. 1 API шлюз → backend

Бэкендерге HTTP/2, 'max _ concurrent _ streams = 200'.
Шлюз торабындағы сервиске 20-40 коннект пулы.
Таймауттар: connect 100ms, per-try 300-500ms, жалпы 1-2s, джиттермен 1 retry.

11. 2 PgBouncer арқылы → PostgreSQL қызметі

'pool _ mode = transaction', 'default _ pool _ size' формуласы бойынша (RPS × W × 1. 3).
'connectionTimeout ≤ 250ms' бағдарламасында, қысқа транзакциялар (<100ms).
Ауыр есеп беру сұраулары - жеке пул/реплика.

11. 3 gRPC ішкі

100-200 ағын лимиті бар мақсатты хостқа бір арна (HTTP/2).
SLO бағыты бойынша RPC-ге Deadline, тек idempotent.
Ұзын RPC және hold-time метрикасы үшін сэмплинг трестері.

12) Енгізу чек-парағы (0-30 күн)

0-7 күн

Негізгі бағыттарда/клиенттерде 'W' (hold-time) өлшеңіз.
'N _ min = λ × W' деп есептеңіз және 30-50% headroom қосыңыз.
keep-alive және қысқа коннект күту уақытын қосыңыз.

8-20 күн

Пулдарды бөліңіз (жылдам/баяу/сыртқы).
circuit-breakers және budgets ретрайлерін енгізіңіз.
Дашбордтар қосыңыз: pool wait p95, reuse ratio, in-flight.

21-30 күн

Бурсты жүктемемен жүгіру, хаос-тест «бэкендтің құлауы».
Қалдықтар бойынша оңтайландыру: ауыр бағыттарды оқшаулау, жергілікті кэштер.
runbook 'ax бағдарламасындағы формулалар мен лимиттерді құжаттаңыз.

13) Қарсы үлгілер

Пулдың өлшемі «кездейсоқ» және headroom болмауы.
Коннектіні күтудің үлкен таймауттары → жылдам істен шығудың орнына ұзын құйрықтар.
Джиттер мен идемпотенттілігі жоқ көптеген ретрациялар → дауыл.
Сұраулардың барлық түрлеріне ортақ бір пул.
Ұзақ транзакциялар коннекті (DB) → басқалардың starvation ұстайды.
Өшірілген keep-alive немесе өте кішкентай idle → churn лимиттері және TTFB өсуі.

14) Жетілу метрикасы

Pool wait p95 <10% жалпы маршруттың p95.
Reuse ratio (> 90% ішкі HTTP үшін;> 80% сыртқы үшін).
DB txn time p95 < 100–200 ms; ұзақ транзакциялардың үлесі <1%.
Retry rate <5% (және ≤ budget), timeouts салдарынан қателер тұрақты және болжамды.
Барлық сыни клиенттер үшін пулдың құжатталған есебі.

15) Қорытынды

Тиімді connection pooling - бұл кезек инженериясы + таймауттар тәртібі. 'W' өлшеңіз, 'λ × W' пулын сақтаумен есептеңіз, keep-alive/HTTP2 + қосыңыз, баяу жолдарды бөліңіз, қысқа таймауттарды және ең аз ретрацияны ұстаңыз. Бақылауға «pool wait vs latency» және circuit-breakers қосыңыз - сіз төмен TTFB, p99 бақыланатын құйрық және бэкендтерді қыздырусыз жарылысқа төзімділік аласыз.