[Python] Deploy con nginx e proxy_pass

[Alessandro Dentella]

On Tue, Dec 24, 2013 at 11:58:05AM +0100, Roberto De Ioris wrote:
> 
> 
> >
> > io sono convinto che se il modello resta round robbin puro, anche se
> > raddoppiassi i processi avrei solo dimezzato la probabilità di incapare in
> > una chiamata "lunga", mentre se potessi evitare di passare chiamate ad un
> > processo che sta lavorando eviterei proprio questa cosa.
> >
> >
> >> aggancia una strace ai processi tornado durante un blocco per vedere che
> >> succede. Probabilmente non ci sara' molto da fare se non aggiungere
> >> altri
> >> processi tornado (sempre che sia tollerabile dall'applicazione).
> >
> > le chiamate lunghe non sono chiamate che a random prendono tanto tempo,
> > sono
> > chiamate che "fanno molte cose" probabilmente non ottimizzate, ma sulle
> > quali io non ho diretto controllo (sono inizializzazioni mensili di alcune
> > posizioni).
> >
> > Grazie per il suggeriemnto
> > sandro
> > *:-)
> 
> Nginx non puo' farlo (vedi pero' nota sotto)
> 
> L'approccio migliore (o meglio diciamo quello risolutivo) e' che i
> processi usino lo stesso socket, puoi provare il plugin tornado di uWSGI:
> 
> http://uwsgi-docs.readthedocs.org/en/latest/Tornado.html
> 
> ma non e' compilato di default (per motivi altamente tecnici: ovvero odio
> la programmazione callback based e non voglio incentivarla ulteriormente
> ;)
> 
> anche gunicorn ha un worker model per tornado ma e' deprecato (ma presumo
> funzioni ancora)
> 
> Nota:
> Se abbassi la listen queue del socket dentro tornado a 1 (in alcuni kernel
> puoi metterla anche a 0 che sarebeb addirittura meglio), otterrai subito
> un errore in caso di worker occupato e nginx passera' la richiesta al
> backend successivo. E' un buon trucco (anche se poco diffuso) nel tuo caso
> specifico.

Grazie Roberto,

non mi è chiaro se il suggerimento di abbassare la listen queue possa essere
usato indipendentemente da uwsgi (come credo). In questo caso non ho capito
come farlo. Non ho trovato parametri di tornado. Credo che quello che
suggerisci sia poi la backlog della socket.listen() ma veramente non ho
alcuna competenza di questo campo...


Al momento, dopo essere passato a nginx 1.4+, un tornado minimale di test
con 2 handler uno che risponde subito e l'altro che si blocca, arrivo ad una
situazione ottimale fino a che uno  abortisce la richiesta. A quel punto ho
la sensazione che nginx azzeri la lista di connessione attive per una porta
particolare mentre tornado resta appeso. Nginx passa la prossima chiamata a
quella porta ed il tutto si blocca.

Mi pare di capire che la soluzione della listen queue che mi hai indicato
risolverebbe questo problema.

sandro
*:-)


PS: ho letto la documentazione del plugin di tornado di uWSGI, mi pare
    relativamete semplice ma non ho ancora avuto tempo di provarla