Python sock.listen (...)

Tutti gli esempi che ho visto di sock.listen(5) nella documentazione di Python suggeriscono di impostare il numero massimo di backlog su 5. Ciò sta causando un problema alla mia app poiché mi aspetto un volume molto elevato (molte connessioni simultanee). L'ho impostato su 200 e non ho riscontrato problemi sul mio sistema, ma mi chiedevo quanto in alto posso impostarlo prima che causi problemi ..Python sock.listen (...)

Qualcuno sa?

Modifica: ecco il mio ciclo accept().

while True:  
    try: 
     self.q.put(sock.accept()) 
    except KeyboardInterrupt: 
     break 
    except Exception, e: 
     self.log("ERR %s" % e)

fonte

2010-03-15 Ian

Alcune informazioni qui: http://stackoverflow.com/questions/114874/socket-listen-backlog-parameter-how-to-determine-this-value –

Ho appena controllato il valore di 'socket.SOMAXCONN' e ho notato il suo '128', che spiegherebbe perché l'impostazione del valore su 200 non ha funzionato per' ab -c 200' (funzionava solo per una concorrenza di 120). – Ian

Utilizzare invece self.q.put_nowait(). –

Il doc dicono che questo

socket.listen(backlog) ascolto per connessioni fatte alla presa. L'argomento backlog specifica il numero massimo di connessioni in coda e deve essere almeno 1; il valore massimo di dipende dal sistema (solitamente 5).

Ovviamente il valore di sistema è più di 5 sul sistema. Non vedo perché impostarlo su un numero maggiore sarebbe un problema. Forse un po 'di memoria è riservata per ogni connessione in coda.

La mia pagina di manuale di Linux ha questo da dire

Se l'argomento backlog è maggiore del valore nel /proc/sys/net/core/SOMAXCONN, allora è silenziosamente troncato a tale valore; il valore di default in questo file è 128. Nei kernel 2.4.25 prima, questo limite è un valore codificato duro, SOMAXCONN, con il valore 128.

fonte

2010-03-15 00:45:18

Appena verificato su osx, 'socket.SOMAXCONN' è anche 128. Un po 'fa schifo, significa che il numero massimo di connessioni in attesa è 128 .. Certo, è molto, ma data la natura breve/veloce di queste richieste .. I speravo in una maggiore concorrenza. – Ian

No, il kernel non riuscirà a soddisfare le richieste di connessione ACK dopo SOMAXCONN. Questo è il comportamento desiderato; se si stanno davvero tenendo più di 128 richieste di connessione in coda, si sta a) impiegando troppo tempo per elaborarle o b) è necessario un server distribuito pesante o c) che soffre di un attacco DDoS. – msw

@Ian, su linux puoi 'echo 256>/proc/sys/net/core/somaxconn'. Tuttavia, dovresti sforzarti di rendere il tuo gestore più veloce prima di aumentare questo numero indipendentemente dallo –

che non è necessario per regolare il parametro di listen() a un numero superiore a 5.

Il parametro controlla quante connessioni non-accept() possono essere in attesa. Il parametro listen() non ha alcuna influenza sul numero di socket connessi contemporaneamente, solo sul numero di connessioni simultanee che non sono state accept() -ed dal processo.

Se la regolazione del parametro su listen() ha un impatto sul codice, è un sintomo che si verifica troppo ritardo tra ogni chiamata a accept(). Dovresti quindi modificare il ciclo accept() in modo che abbia un sovraccarico minore.

Nel tuo caso, sto indovinando che self.q è un pitone queue, nel qual caso si consiglia di chiamare self.q.put_nowait() per evitare ogni possibilità di bloccare il ciclo accept() a questa chiamata.

fonte

2010-03-15 00:49:41

Se è vero, c'è qualcosa di sbagliato in 'ab', perché l'aumento della dimensione di' backlog' ha risolto i miei problemi. – Ian

@Heath, è possibile se ci sono un sacco di connessioni fatte ogni secondo. Un grande backlog ti consentirà di migliorare il carico transitorio –

@Ian: Cos'è "ab"? Come ho scritto nella mia risposta, se aumentare il backlog risolve il tuo problema, significa che non stai chiamando accept() abbastanza frequentemente per stare al passo con le connessioni in entrata. Come funziona il tuo codice accept()? –

risposta

Problemi correlati