Willy mi ha dato una risposta via e-mail. Ho pensato di condividerlo. Le sue risposte sono in grassetto.
Ho una domanda sulla mia configurazione haproxy:
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
log 127.0.0.1 syslog emerg
maxconn 4000
quiet
user haproxy
group haproxy
daemon
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
log global
option abortonclose
option dontlognull
option httpclose
option httplog
option forwardfor
option redispatch
timeout connect 10000 # default 10 second time out if a backend is not found
timeout client 300000 # 5 min timeout for client
timeout server 300000 # 5 min timeout for server
stats enable
listen http_proxy localhost:81
balance roundrobin
option httpchk GET /empty.html
server server1 myip:80 maxconn 15 check inter 10000
server server2 myip:80 maxconn 15 check inter 10000
Come puoi vedere è semplice, ma sono un po 'confuso su come funzionano le proprietà maxconn.
C'è quello globale e il maxconn sul server, nel blocco di ascolto.
E ce n'è anche un altro nel blocco di ascolto che ha come valore predefinito qualcosa come 2000.
Il mio pensiero è questo: quello globale gestisce il numero totale di connessioni che haproxy, come servizio, accoderà o elaborerà contemporaneamente.
Corretta. È il numero massimo di connessioni simultanee per processo.
Se il numero supera quello, o interrompe la connessione, o si accumula in qualche socket Linux?
Successivamente, smette semplicemente di accettare nuove connessioni e rimangono nella coda dei socket nel kernel. Il numero di socket accodabili è determinato dal numero minimo di (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog e maxconn del blocco di ascolto).
Non ho idea di cosa succeda se il numero supera 4000.
Le connessioni in eccesso attendono il completamento di un altro prima di essere accettate. Tuttavia, fintanto che la coda del kernel non è satura, il client non se ne accorge nemmeno, poiché la connessione è accettata a livello TCP ma non viene elaborata. Quindi il cliente nota solo un certo ritardo nell'elaborazione della richiesta. Ma in pratica, il maxconn del blocco di ascolto è molto più importante, poiché di default è più piccolo di quello globale. Il maxconn dell'ascolto limita il numero di connessioni per ascoltatore. In generale è saggio configurarlo per il numero di connessioni che desideri per il servizio e configurare il maxconn globale al numero massimo di connessioni che lasci gestire al processo haproxy. Quando si dispone di un solo servizio, entrambi possono essere impostati sullo stesso valore. Ma quando hai molti servizi,
Quindi hai la proprietà maxconn del server impostata su 15. Prima di tutto, l'ho impostata su 15 perché il mio php-fpm, questo viene inoltrato a un server separato, ha solo così tanti processi figli che può usare, quindi mi assicuro di essere raggruppare le richieste qui, invece che in php-fpm. Che penso sia più veloce.
Sì, non solo dovrebbe essere più veloce, ma consente ad haproxy di trovare un altro server disponibile quando possibile, e gli permette anche di terminare la richiesta in coda se il client preme "stop" prima che la connessione venga inoltrata al server.
Ma tornando all'argomento, la mia teoria su questo numero è che ogni server in questo blocco riceverà solo 15 connessioni alla volta. E poi le connessioni aspetteranno un server aperto. Se avessi i cookie, le connessioni aspetterebbero il server aperto CORRETTO. Ma io no.
Questo è esattamente il principio. C'è una coda per proxy e una coda per server. Le connessioni con un cookie di persistenza vanno alla coda del server e altre connessioni vanno alla coda del proxy. Tuttavia, poiché nel tuo caso non è configurato alcun cookie, tutte le connessioni vanno alla coda del proxy. Puoi guardare il diagramma doc / queuing.fig nei sorgenti haproxy se vuoi, spiega come / dove vengono prese le decisioni.
Quindi le domande sono:
Cosa succede se le connessioni globali superano i 4000? Muoiono? O pool in Linux in qualche modo?
Sono in coda in Linux. Una volta che si supera la coda del kernel, vengono rilasciati nel kernel.
La connessione globale è correlata alle connessioni al server, a parte il fatto che non puoi avere un numero totale di connessioni al server maggiore di quello globale?
No, le impostazioni di connessione globale e del server sono indipendenti.
Quando si calcolano le connessioni globali, non dovrebbe essere la quantità di connessioni sommate nella sezione server, più una certa percentuale per il pool? E ovviamente hai altri vincoli sui collegamenti, ma davvero quanti ne vuoi inviare ai proxy?
Hai capito bene. Se il tempo di risposta del tuo server è breve, non c'è niente di sbagliato nell'accodare migliaia di connessioni per servirne solo poche alla volta, perché riduce sostanzialmente il tempo di elaborazione della richiesta. In pratica, stabilire una connessione oggigiorno richiede circa 5 microsecondi su una LAN gigabit. Quindi ha molto senso lasciare che haproxy distribuisca le connessioni il più velocemente possibile dalla sua coda a un server con un maxconn molto piccolo. Ricordo un sito di giochi in coda per più di 30000 connessioni simultanee e in esecuzione con una coda di 30 per server! Era un server Apache e apache è molto più veloce con un numero ridotto di connessioni che con un numero elevato. Ma per questo hai davvero bisogno di un server veloce, perché non Voglio che tutti i tuoi client siano in coda in attesa di uno slot di connessione perché il server sta aspettando un database, ad esempio. Un'altra cosa che funziona molto bene è dedicare server. Se il tuo sito ha molte statistiche, puoi indirizzare le richieste statiche a un pool di server (o cache) in modo da non accodare richieste statiche su di essi e che le richieste statiche non mangino costosi slot di connessione. Spero che questo aiuti, Willy