Pool байланыш жана latency

Pool байланыш жана latency

1) Эмне үчүн бассейндер керек

• Даяр коннекттерди кайра колдонуу (keep-alive) → TTFB төмөн.
• Параллелизмди көзөмөлдөө жана ретрайлардын көчкүнүн ордуна backpressure берүү.
• p95/p99 куйруктарын туура өлчөмдөрү жана убакыттын өтүшү менен азайтуу.

Негизги тобокелдиктер: пулда күтүү кезектери, head-of-line blocking, коннектилер жана бороон-чапкын үчүн контеншен.

2) Математика базасы: бассейндин өлчөмүн кантип эсептөө керек

• 'λ' - орточо суроо-талап агымы (RPS).
• 'W' - суроо-талап боюнча байланыштын орточо бош эместиги (тейлөө убактысы, анын ичинде тармактык жашыруун жана алыскы кызматтын иштеши).
• Минималдуу көлөм: 'N _ min ≈ λ × W'.
• Вариация жана p99 үчүн запас кошуу: headroom 20-50%.
• Мисалы: 300 RPS, орточо кармоо убактысы 40 мс → 'N _ min = 300 × 0. 04 = 12`. 50% → 18 коннектилер менен.

Эгерде куйруктар чоң болсо: критикалык жолдор үчүн 'W _ p95' же 'W _ p99' эске алыңыз - пулдар өсөт.

3) Долбоорлоонун жалпы принциптери

1. Кыска маалымат жолу: reuse (keep-alive, HTTP/2/3 multiplexing).
2. Параллелизмди чектөө: бат эле (429/503) кайра кайнатып караганда жакшы.
3. Таймауттар> ретрайлер: чакан таймауттарды жана сейрек кездешүүчү ретраларды джиттер менен коюңуз.
4. Кардардын кезектери серверге караганда кыска (Fast Fail).
5. Backpressure: бассейн толтурулган - дароо NACK/ката/colback "кийин".
6. Максаттар боюнча пулдарды изоляциялоо: DB, кэш, тышкы PSP - алардын лимиттери.

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

HTTP/1. 1: бир эле учурда коннектке бир суроо-талап (иш жүзүндө); хост үчүн бир нече байланыштар менен бассейн керек.
HTTP/2: бир TCP агымын multiplexing; аз байланыштар, бирок пакеттерин жоготуу менен TCP боюнча HOL-blocking мүмкүн.
HTTP/3 (QUIC): UDP үстүнөн көз карандысыздык агымы - аз HOL көйгөйлөр, тез биринчи байт.

• keep-alive timeout 30-90s (профиль боюнча), коннектке суроо лимити (graceful recycle).
• Preconnect (preconnect) worker башталганда.
• 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) BD Пулдар: 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

• Pool 'λ × 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 (кыска: 50-250 ms ичинде DC).
2. TLS handshake timeout (500–1000 ms вне DC).
3. Request/Read timeout (SLO маршруту жакын).
4. Retry: максимум 1 жолу, гана idempotent ыкмалары үчүн; життер + backoff.
5. Retraia боюнча Budget: RPS пайыздык дүйнөлүк чеги (мисалы, ≤ 10%).

8) Keep-alive, Nagle, протоколдор

Чакан билдирүүлөр менен RPC үчүн Nagle (TCP_NODELAY) өчүрүү.
HTTP keep-alive мүмкүн болгон жерде күйгүзүү.
Карап TIME_WAIT - tune 'reuse '/' recycle' гана кесепеттерин түшүнсөңүз; жакшыраак - reuse connections эмес, негизги тюнинг.
TLS: session resumption жана ALPN колдонуңуз.

9) OS/Kernel тюнинг (этияттык менен)

`net. core. somaxconn`, `net. ipv4. ip_local_port_range`, `net. ipv4. tcp_fin_timeout`.
Descriptors: 'nofile' ≥ 64k proxy жараяны.
IRQ балансы, GRO/LRO - трафиктин профили боюнча.
артыкчылык - кароо; өлчөгүч жок тюнинг көп зыян.

10) Байкоо: эмне өлчөө керек

Pool utilization: ээлеген/жалпы, p50/p95 коннектинин күтүү.
In-flight суроолор жана алардын hold-time (каттамдар боюнча кесип).
Error budget retrains: кайталоо үлүшү.
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) Case Recipes

11. 1 API шлюз → backend

HTTP/2, 'max _ concurrent _ streams = 200'.
Бассейн шлюз түйүнүнө кызмат үчүн 20-40 коннектилер.
Таймауттар: connect 100ms, per-try 300-500ms, жалпы 1-2s, 1 retry jitter менен.

11. 2 кызмат → PgBouncer аркылуу PostgreSQL

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

11. 3 gRPC ички

Бир канал (HTTP/2) 100-200 агымынын чеги менен максаттуу хост.
SLO маршруту боюнча RPC боюнча Deadline, retry гана idempotent.
узак RPC жана hold-time метрика үчүн Самплинг Traces.

12) киргизүү чек-тизмеси (0-30 күн)

0-7 күн

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

8-20 күн

бөлүү пулдар (тез/жай/тышкы).
circuit-breakers жана retrains budgets киргизүү.
dashboard кошуу: pool wait p95, reuse ratio, in-flight.

21-30 күн

Bourstes менен жүгүрүү, башаламандык-тест "күзүндө".
куйруктары боюнча оптималдаштыруу: оор жолдорду изоляциялоо, жергиликтүү кэш.
runbook 'ax менен формулаларды жана чектөөлөрдү документтештирүү.

13) Анти-үлгүлөрү

бассейн көлөмү "кокусунан" жана headroom жоктугу.
Чоң күтүү убактысы → узун куйруктары ордуна тез ийгиликсиз.
Көп retrains жок Jitter жана боштондук → бороон.
суроо-талаптардын бардык түрлөрү үчүн бир жалпы бассейн.
Узак бүтүмдөр коннектти кармап (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 башкарылуучу куйругу жана ашыкча ысып жок жарылууга туруктуулук болот.