Δεξαμενές σύνδεσης και καθυστέρηση

Ομάδες σύνδεσης και καθυστέρηση

1) Γιατί χρειάζονται κοινοπραξίες

• Επαναχρησιμοποίηση έτοιμων συνδέσεων (διατηρούνται ζωντανές) → κάτω από την TTFB.
• Ελέγχει το νόμισμα και δίνει αντίθλιψη αντί για χιονοστιβάδα υποχωρήσεων.
• Μειώστε τις ουρές p95/p99 λόγω του σωστού μεγέθους και των χρονοδιαγραμμάτων.

Βασικοί κίνδυνοι: ουρές αναμονής στην πισίνα, μπλοκάρισμα κεφαλής γραμμής, περιεχόμενο για συνδέσεις και θύελλα υποχώρησης.

2) Βάση μαθηματικών: Πώς να μετρήσετε το μέγεθος της πισίνας

• 'λ' είναι η μέση ροή αιτήσεων (RPS).
• «W» είναι η μέση σύνδεση που είναι απασχολημένη ανά αίτηση (χρόνος υπηρεσίας, συμπεριλαμβανομένης της καθυστέρησης δικτύου και της λειτουργίας εξ αποστάσεως υπηρεσίας).
• Το ελάχιστο μέγεθος συγκέντρωσης είναι «N _ min ≈ λ × W».
• Να προστεθεί περιθώριο διακύμανσης και p99: κεφαλή 20-50%.
• Παράδειγμα: 300 RPS, μέσος χρόνος αναμονής 40 ms → 'N _ min = 300 × 0. 04 = 12`. Με περιθώριο 50%, → 18 συνδέσεις.

Αν οι ουρές είναι μεγάλες: σκεφτείτε 'W _ p95' ή 'W _ p99' για κρίσιμες διαδρομές - οι πισίνες μεγαλώνουν.

3) Γενικές αρχές σχεδιασμού

1. Σύντομη διαδρομή δεδομένων: επαναχρησιμοποίηση (συνεχής, HTTP/2/3 πολυπλέκτης).
2. Περιορισμός του παραλληλισμού: είναι προτιμότερο να αρνείται κανείς γρήγορα (429/503) παρά να τηγανίζει το υπόβαθρο.
3. Timeouts> υποχωρήσεις: Ρυθμίστε μικρά timeouts και σπάνια jitter υποχωρήσεις.
4. Οι ουρές του πελάτη είναι μικρότερες από τις ουρές του διακομιστή (γρήγορη αστοχία).
5. Backpressure: όταν η δεξαμενή είναι πλήρης - αμέσως NACK/σφάλμα/collbeck «αργότερα».
6. Απομόνωση κοινοπραξιών ανά στόχο: DB, κρύπτη, εξωτερικό PSP - τα όριά τους.

4) HTTP/1. 1 έναντι HTTP/2/3, διατηρούμενη ζωντανή

. 1: μία αίτηση σύνδεσης κάθε φορά (πρακτικά)· χρειάζονται μια δεξαμενή με πολλαπλές συνδέσεις ανά ξενιστή.
: πολλαπλασιασμός ρεύματος σε ένα TCP· λιγότερες συνδέσεις, αλλά ο αποκλεισμός HOL σε TCP είναι δυνατός όταν χάνονται πακέτα.
(QUIC): streaming ανεξαρτησία έναντι UDP - λιγότερα προβλήματα HOL, γρηγορότερες πρώτες ψηφιολέξεις.

• διατήρηση του χρόνου 30-90 (ανά προφίλ), όριο των αιτήσεων σύνδεσης (χαριτωμένη ανακύκλωση).
• Προθέρμανση (πρόγνωση) στην αρχή του εργαζομένου.
• Περιορισμός των μέγιστων ροών ανά 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) DB Pools: PgBouncer, HikariCP, οδηγοί

Στόχος είναι ο περιορισμός των ανταγωνιστικών συναλλαγών και η διατήρηση της στενής σύνδεσης.

5. 1 PgBouncer (PostgreSQL)

Τρόποι: «συνεδρία »/« συναλλαγή »/« δήλωση». Για API - συχνότερες συναλλαγές.
Σημαντικές παράμετροι είναι οι '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 (Ιάβα)

Μικρές, γρήγορες συνδέσεις, δύσκολα χρονοδιαγράμματα.

properties dataSourceClassName=org. postgresql. ds. PGSimpleDataSource maximumPoolSize=30 minimumIdle=5 connectionTimeout=250 validationTimeout=200 idleTimeout=30000 maxLifetime=1800000 leakDetectionThreshold=5000

• «maximum Μέγεθος RPS × W × κεφαλή».
• "connorfortttTimeout 'hundreds of miliseconds, not seconds.
• Ενεργοποίηση ανίχνευσης διαρροής.

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) Ουρές αναμονής και καθυστέρηση στην ουρά

• Η δεξαμενή είναι μικρότερη από 'λ × W' → η ουρά σύνδεσης αυξάνεται.
• Φορτίο ανομοιογένειας (εκρήξεις) χωρίς ρυθμιστικό διάλυμα και όρια.
• Μακροχρόνια αιτήματα λαμβάνουν τη σύνδεση και δημιουργούν ένα HOL.

• Χωριστές ομάδες ανά τύπο αιτήματος (γρήγορη/αργή).
• Εφαρμογή χρονοδιαγράμματος από την πλευρά του πελάτη. Αν έχει λήξει - γρήγορο NACK.
• Πιο ακραία ανίχνευση και διακοπή κυκλωμάτων σε διαδρομές (Απεσταλμένος, HAProxy).
• Ποσοστώσεις για «βαριές» διαδρομές, ξεχωριστή ομάδα για εκθέσεις/εξαγωγές.

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

7) Χρονοδιαγράμματα και υποχωρήσεις (σωστή σειρά)

1. Σύνδεση timeout (σύντομη: 50-250 ms εντός ΣΡ).
2. TLS timeout χειραψίας (500-1000 ms вне DC).
3. Αίτημα/ανάγνωση χρονοδιαγράμματος (πλησιέστερα στη διαδρομή SLO).
4. Επαναδραστηριοποίηση: μέγιστη 1 φορά, μόνο για idempotent μεθόδους. jitter + backoff.
5. Προϋπολογισμός επαναπροσδιορισμού: συνολικό όριο ως ποσοστό της RPS (π.χ. ≤ 10%).

8) Φυλάσσετε στη ζωή, Nagle, πρωτόκολλα

Απενεργοποίηση Nagle (TCP_NODELAY) για RPC μικρών μηνυμάτων.
Ενεργοποιήστε το HTTP να διατηρείται ζωντανό όπου είναι δυνατόν.
Παρακολουθήστε το TIME_WAIT - συντονίστε «επαναχρησιμοποίηση »/« ανακύκλωση» μόνο εάν κατανοείτε τις συνέπειες. Καλύτερη - επαναχρησιμοποίηση συνδέσεων, όχι ρύθμιση πυρήνα.
TLS - Επανάληψη συνεδρίας και ALPN.

9) Συντονισμός OS/Kernel (με προσοχή)

'net. ο πυρήνας. somaxcon , "δίχτυ. ipv4. , 'net. ipv4. .
Περιγραφές: 'nofile' ≥ 64k ανά διαμεσολαβητή.
Ισοζύγιο IRQ, GRO/LRO - ανά προφίλ κυκλοφορίας.
Προτεραιότητα - προφίλ· η ρύθμιση χωρίς μετρήσεις είναι συχνά επιβλαβής.

10) Παρατηρησιμότητα: τι να μετρήσετε

Χρήση της δεξαμενής: απασχολημένος/σύνολο, p50/p95 σύνδεση εκκρεμεί.
Αιτήματα πτήσης και χρόνος αναμονής (φέτες διαδρομής).
Επαναπροσδιορισμός του προϋπολογισμού σφάλματος: ποσοστό επαναλήψεων.
Σύνδεση churn Δημιουργία/Κλείσιμο ανά δευτερόλεπτο.
TCP/TLS: SYN RTT, χειραψίες, επαναχρησιμοποίηση συνεδρίας.
: ενεργές συνδέσεις, αναμονή, μεγάλες συναλλαγές, κλειδαριές.

: "RPS vs pool wait", "hold-time distribution", "reuse ratio", "circuit trip Графики.

11) Συνταγές υποθέσεων

11. 1 πύλη API - backend

σε backends, 'max _ ταυτόχρονα _ ρεύματα = 200'.
Κοινοπραξία 20-40 συνδέσεων ανά υπηρεσία ανά κόμβο πύλης.
Timeouts: σύνδεση 100ms, ανά δοκιμή 300-500ms, κοινή 1-2s, 1 επανάληψη με νευρικότητα.

11. 2 Υπηρεσία PostgreSQL μέσω PgBouncer

'pool _ mode = συναλλαγή', 'default _ pool _ size' κατά τύπο (RPS × W × 1. 3).
Σε «connectionTimeout≤250ms», ανοικτές συναλλαγές (<100ms).
Βαριές αιτήσεις υποβολής εκθέσεων - χωριστή κοινοπραξία/αντίγραφο.

11. 3 gRPC εσωτερικό

Ένα κανάλι (HTTP/2) ανά ξενιστή-στόχο με όριο νήματος 100-200.
Προθεσμία για RPC στη διαδρομή SLO, επαναπροσδιορισμός μόνο idempotent.
Long RPC δειγματοληψία ιχνών και μετρήσεις χρόνου αναμονής.

12) Κατάλογος ελέγχου εφαρμογής (0-30 ημέρες)

0- 7 ηµέρες

Μέτρο «W» (χρόνος αναμονής) σε βασικές διαδρομές/πελάτες.
Υπολογίστε 'N _ min = λ × W' και προσθέστε 30-50% headroom.
Ενεργοποίηση χρονοδιαγραμμάτων διατήρησης και σύντομης σύνδεσης.

8- 20 ημέρες

Χωριστές ομάδες (ταχείες/αργές/εξωτερικές).
Τύπος διακοπτών κυκλωμάτων και προϋπολογισμοί επαναπροσδιορισμού.
Προσθήκη ταμπλό: πισίνα αναμονής p95, λόγος επαναχρησιμοποίησης, κατά την πτήση.

21- 30 ημέρες

Το φορτίο εκτελείται με εκρήξεις, δοκιμή χάους "πτώση του backen .
Βελτιστοποίηση ουράς: απομόνωση βαρέων διαδρομών, τοπικών κρυψώνων.
Τύποι εγγράφων και όρια στο runbook 'ax.

13) Αντι-μοτίβα

Μέγεθος κοινοπραξίας «τυχαία» και χωρίς κεφαλότοπο.
Μεγάλα χρονικά περιθώρια αναμονής → μακριές ουρές αντί για γρήγορες αποτυχίες.
Πολλές υποχωρήσεις χωρίς νευρικότητα και ευεξία → μια καταιγίδα.
Μια κοινή κοινοπραξία για όλους τους τύπους αιτήσεων.
Οι μακροχρόνιες συναλλαγές διατηρούν τη σύνδεση (DB) → την πείνα των υπολοίπων.
Άτομα με ειδικές ανάγκες διατηρούνται ζωντανά ή πολύ μικρά όρια αδράνειας και ανάπτυξη TTFB.

14) Μετρήσεις διάρκειας

p95 σε prod <10% της συνολικής διαδρομής p95.
Λόγος επαναχρησιμοποίησης (> 90% για το εσωτερικό HTTP·> 80% για εξωτερικούς).
DB txn χρόνος p95 <100-200 ms, ποσοστό μακρών συναλλαγών <1%.
Ποσοστό επαναπροσδιορισμού <5% (και ≤ προϋπολογισμός), τα σφάλματα λόγω χρονοδιαγραμμάτων είναι σταθερά και προβλέψιμα.
Τεκμηριωμένος διακανονισμός συγκέντρωσης για όλους τους κρίσιμους πελάτες.

15) Συμπέρασμα

Η αποτελεσματική συγκέντρωση συνδέσεων είναι η μηχανική αναμονής + η πειθαρχία timeout. Μετρήστε 'W', υπολογίστε τη δεξαμενή 'λ × W' με ένα περιθώριο, ενεργοποιήστε keep-alive/HTTP2 +, ξεχωριστές αργές διαδρομές, κρατήστε σύντομες χρονικές περιόδους και ελάχιστες ρετράς με νευρικότητα. Προσθέστε την παρατηρησιμότητα «pool wait vs latency» και τους διακόπτες κυκλώματος - και παίρνετε χαμηλή TTFB, ελεγχόμενη ουρά p99 και αντίσταση κύματος χωρίς υπερθέρμανση backends.