[Python] Deploy con nginx e proxy_pass

[Roberto De Ioris]

> 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.
>


server = HTTPServer(app)
server.bind(post, backlog=1)

(prova anche con zero, su alcuni kernel funziona, anche se non ricordo se
e' per quelli piu' recenti o quelli piu' vecchi)


-- 
Roberto De Ioris
http://unbit.it