[Python] Deploy con nginx e proxy_pass

Alessandro Dentella sandro a e-den.it
Ven 3 Gen 2014 18:42:36 CET


On Fri, Jan 03, 2014 at 12:45:02PM +0100, Manlio Perillo wrote:
> On 03/01/2014 12:34, Alessandro Dentella wrote:
> >[...]
> >La nostra simulazione è stata fatta con 2 funzioni: is_up e blocking che usa
> >time.sleep()
> >
> >    class IsUp(tornado.web.RequestHandler):
> >        def get(self):
> >            self.write("Is Up Porta %d" ...)
> >    	self.finish()
> >
> >    class Blocking(tornado.web.RequestHandler):
> >        def get(self, numero=10):
> >            time.sleep(int(numero))
> >    	self.write("Bloccato Porta %s\n" % options.port)
> >    	self.finish()
> >
> >la chiamata usando 'wget -q -O - http://ngtest/blocking/30/' ed
> >interrompendolo con Control-c.
> 
> Ok.
> Ma quante instanze di tornado hai attive?

10 al momento, vedi descrizione qui [1]

> Se ne hai attiva una sola, mi sembra ovvio che blocca tutto.
> 
> Se ne hai N, facendo N richieste di questo genere blocchi ancora tutto.

Certo ma ho poche richieste bloccanti (2% > 2 secondi) ed un totale molto
basso di richieste lente: 100/giorno >  10 secondi, 300/giorno> 4 secondi.


> >In un terminale separato in ciclo di 'wget -q -O - http://ngtest/is_up'
> >Il ciclo si blocca nel momento della interruzione e riprende solo quando
> >termita il tempo (e quindi il processo si libera)
> >
> 
> Che ciclo?

un for della bash

> Per concludere, tieni conto che usare cose come Tornado è tutt'altro
> che banale.  Tutto lo stack (applicazione + framework + eventuali
> librerie) deve essere sviluppato con la programmazione asincrona in
> mente.  E' vero che ci sono dei monkey patch per alcune funzioni
> della libreria standard, ma non ritengo sia saggio affidarsi
> ciecamente a loro.  Python e la libreria standard semplicemente non
> sono pensati per un ambiente a green thread.


Questo è il peccato originale che non dipende da me all'interno del quale mi
devo muovere. Chi ha scritto l'applicazione non ha capito la specificità di
tornado ed ha fatto una programmazione basata su richieste non asincone.

In questo quadro e per il poco tempo che io mi occupo di questo progetto ho
solo potuto suggerire nell'ordine 1) di passare a django 2) di modificare il
setup per moltiplicare i processi in modo da evitare i blocchi 3) di
ottimizzare alcune funzioni che probabilmente prendono tempo quando non
dovrebbero. 

Come già detto in altra mail, il problema residuo sorge quando una chiamata
viene interrotta. Nginx libera subito la risorsa e passa una nuova chiamata
a quel processo che in realtà è ancora occupato.

sandro


[1] http://comments.gmane.org/gmane.comp.python.general.italian/14562


Maggiori informazioni sulla lista Python