Bağlantı havuzları ve gecikme süresi

Bağlantı havuzları ve gecikme süresi

1) Havuzlara neden ihtiyaç duyulur

• TTFB'nin altındaki hazır bağlantıları (canlı tutun) yeniden kullanın.
• Eşzamanlılığı kontrol edin ve geri çekilme çığ yerine geri tepme verin.
• Doğru boyut ve zaman aşımları nedeniyle p95/p99 kuyruklarını azaltın.

Anahtar riskler: havuzda bekleme kuyrukları, hat başı engelleme, bağlantı içeriği ve geri çekilme fırtınası.

2) Matematik Tabanı: Havuz Boyutu Nasıl Sayılır

• 'λ' ortalama istek akışıdır (RPS).
• 'W', istek başına ortalama meşgul bağlantıdır (servis süresi, ağ gecikmesi ve uzaktan servis işlemi dahil).
• Minimum havuz boyutu 'N _ min ≈ λ × W'dir.
• Varyasyonlar ve p99 için bir kenar boşluğu ekleyin: %20-50 boşluk.
• Örnek: 300 RPS, ortalama tutma süresi 40 ms> 'N _ min = 300 × 0. 04 = 12`. %50'lik bir marjla 18 bağlantı vardır.

Kuyruklar büyükse: kritik yollar için 'W _ p95' veya 'W _ p99' düşünün - havuzlar büyür.

3) Genel tasarım ilkeleri

1. Kısa veri yolu: yeniden kullanım (keep-alive, HTTP/2/3 multiplexing).
2. Paralelliğin sınırlandırılması: arka ucu kızartmaktan daha hızlı bir şekilde (429/503) reddetmek daha iyidir.
3. Zaman aşımları> geri çekilmeler: Küçük zaman aşımları ve nadir jitter geri çekilmeleri ayarlayın.
4. İstemci kuyrukları sunucu kuyruklarından daha kısadır (hızlı ve hızlı).
5. Backpressure: havuz dolduğunda - hemen NACK/hata/collbeck "sonra".
6. Havuzların hedeflere göre izolasyonu: DB, önbellek, harici PSP - sınırları.

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

HTTP/1. 1: bir seferde bir bağlantı isteği (pratik olarak); Ana bilgisayar başına birden fazla bağlantıya sahip bir havuz gerekir.
HTTP/2: bir TCP'de akış çoklaması; Daha az bağlantı, ancak paketler kaybolduğunda TCP'de HOL engelleme mümkündür.
HTTP/3 (QUIC): UDP üzerinden bağımsız akış - daha az HOL problemi, daha hızlı ilk bayt.

• Hayatta kalma zaman aşımı 30-90 (profile göre), bağlantı taleplerinin sınırı (zarif geri dönüşüm).
• İşçinin başlangıcında ön ısıtma (preconnect).
• HTTP/2 başına maksimum akışları sınırlayın (örn. 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 Havuzları: PgBouncer, HikariCP, sürücüler

Amaç, rekabetçi işlemleri sınırlamak ve kısa bağlantı tutucularını tutmaktır.

5. 1 PgBouncer (PostgreSQL)

Modlar: 'Session'/' transaction'/' statement'. API için - daha sık işlem.
Önemli parametreler 'pool _ size','min _ pool _ size ',' reserve _ pool _ size ',' server _ idle _ timeout ',' query _ wait _ timeout'dur.

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)

Küçük, hızlı bağlantılar, zor zamanlar.

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' saniyeler değil milisaniyeler içinde akar.
• Sızıntı tespitini etkinleştir.

5. 3 Git/Düğüm/Python - örnekler

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) Bekleme kuyrukları ve kuyruk gecikmesi

• Havuz 'λ × W'den daha küçüktür - bağlantı kuyruğu büyüyor.
• Tampon ve sınırlar olmadan düzensizlik (patlamalar) yükleyin.
• Uzun istekler bağlantıyı alır ve bir HOL oluşturur.

• İstek türüne göre ayrı havuzlar (hızlı/yavaş).
• İstemci tarafı zaman aşımı uygula. Süresi dolmuşsa - hızlı NACK.
• Güzergahlarda aykırı değer tespiti ve devre kesme (Envoy, HAProxy).
• "Ağır" rotalar için kotalar, raporlar/ihracat için ayrı bir havuz.

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

7) Zaman aşımları ve geri çekilmeler (doğru sipariş)

1. Bağlantı zaman aşımı (kısa: DC içinde 50-250 ms).
2. TLS el sıkışma zaman aşımı (500-1000 ms вне DC).
3. İstek/Okuma zaman aşımı (rota SLO'suna daha yakın).
4. Retry: maksimum 1 kez, sadece idempotent yöntemler için; jitter + backoff.
5. Bütçeyi geri çekme: RPS yüzdesi olarak genel sınır (örneğin, ≤ %10).

8) Keep-alive, Nagle, protokoller

Küçük mesaj RPC'leri için Nagle (TCP_NODELAY) özelliğini devre dışı bırakın.
Mümkün olan her yerde HTTP keep-alive özelliğini etkinleştirin.
TIME_WAIT izleyin - sadece sonuçları anladığınızda 'yeniden kullan'/' geri dönüştür' ayarını yapın; Daha iyisi - çekirdek ayarı değil bağlantıları yeniden kullanın.
TLS - Oturum sürdürme ve ALPN kullanın.

9) OS/Çekirdek ayarı (dikkatli)

'net. Çekirdek. Somaxconn ',' net. ipv4. ip_local_port_range', 'net. ipv4. tcp_fin_timeout'.
Tanımlayıcılar: 'nofile' ≥ proxy işlemi başına 64k.
IRQ dengesi, GRO/LRO - trafik profiline göre.
Öncelik - profil; Metrikler olmadan ayarlama genellikle zararlıdır.

10) Gözlemlenebilirlik: neyin ölçüleceği

Havuz kullanımı: meşgul/toplam, p50/p95 bağlantı beklemede.
Uçuş içi talepler ve bekletme süreleri (rota dilimleri).
Hata bütçesini yeniden ayır: tekrarların oranı.
Bağlantı çalkalama Saniyede oluştur/Kapat.
TCP/TLS: SYN RTT, el sıkışmaları, oturum yeniden kullanımı.
Для БД: aktif bağlantılar, bekleme, uzun işlemler, kilitler.

Графики: "RPS vs havuz bekleme", "bekleme süresi dağılımı", "yeniden kullanım oranı", "devre gezileri".

11) Kasa tarifleri

11. 1 API ağ geçidi - arka uç

Arka uçlara HTTP/2, 'max _ concurrent _ streams = 200'.
Ağ geçidi düğümü başına hizmet başına 20-40 bağlantıdan oluşan bir havuz.
Zaman aşımları: 100ms, deneme başına 300-500ms, paylaşılan 1-2s, 1 jitter ile yeniden deneyin.

11. 2 PostgreSQL PgBouncer üzerinden servis

'pool _ mode = transaction', formüle göre 'default _ pool _ size' (RPS × W × 1. 3).
'connectionTimeout≤250ms', kısa işlemler (<100ms).
Ağır raporlama istekleri - ayrı havuz/çoğaltma.

11. 3 gRPC dahili

100-200 iş parçacığı sınırı olan hedef ana bilgisayar başına bir kanal (HTTP/2).
SLO rotasında RPC'de son tarih, sadece idempotent'i geri alın.
Uzun RPC izleme örneklemesi ve bekletme süresi metrikleri.

12) Uygulama kontrol listesi (0-30 gün)

0-7 gün

Önemli güzergahlarda/istemcilerde 'W' (bekleme süresi) ölçün.
'N _ min = λ × W' hesaplayın ve %30-50 boşluk ekleyin.
Canlı ve kısa bağlantı zaman aşımlarını etkinleştirin.

8-20 gün

Ayrı havuzlar (hızlı/yavaş/harici).
Devre kesiciler yazın ve bütçeleri yeniden ödeyin.
Panoları ekleyin: havuz bekleme p95, yeniden kullanım oranı, uçuş sırasında.

21-30 gün

Yük patlamalarla çalışır, kaos testi "arka uçtan düşer".
Kuyruk optimizasyonu: ağır yolların izolasyonu, yerel önbellekler.
Belge formülleri ve sınırları runbook 'axda.

13) Anti-desenler

Havuz büyüklüğü "rastgele've boşluk yok.
Büyük bağlantı bekleme süreleri - hızlı arızalar yerine uzun kuyruklar.
Birçok jitter ve idempotency olmadan inzivaya çekilir - bir fırtına.
Tüm istek türleri için paylaşılan bir havuz.
Uzun işlemler bağlantıyı korur (DB) - geri kalanların açlığı.
Canlı kalma veya çok küçük boşta kalma - çalkalama sınırları ve TTFB büyümesi.

14) Olgunluk metrikleri

Havuz bekleme p95 içinde prod <10 % toplam p95 rota.
Yeniden kullanım oranı (dahili HTTP için> %90;> %80 dış).
DB txn time p95 <100-200 ms; Uzun işlemlerin yüzdesi <%1.
Yeniden deneme oranı <%5 (ve ≤ bütçe), zaman aşımlarından kaynaklanan hatalar istikrarlı ve öngörülebilirdir.
Tüm kritik müşteriler için belgelenmiş havuz yerleşimi.

15) Sonuç

Etkili bağlantı havuzu kuyruk mühendisliği + zaman aşımı disiplinidir. 'W' ölçün, bir kenar boşluğu ile 'λ × W' havuzunu hesaplayın, keep-alive/HTTP2 +'yı açın, yavaş yolları ayırın, kısa zaman aşımları ve jitter ile minimum retras tutun. "Havuz bekleme vs gecikme" gözlemlenebilirlik ve devre kesiciler ekleyin - ve düşük TTFB, kontrollü p99 kuyruk ve aşırı ısınma arka uçları olmadan dalgalanma direnci olsun.