[Python] Deploy con nginx e proxy_pass

[Alessandro Dentella]

On Fri, Jan 03, 2014 at 12:50:54PM +0100, Roberto De Ioris wrote:
> 
> > On Mon, Dec 30, 2013 at 05:26:57PM +0100, Roberto De Ioris wrote:
> >> > 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)
> >
> > Purtroppo questa strada non ha funzionato. Ricordo che il probelma che
> > cerchiamo di risolvere è che quando viene interrotto una chiamata "lunga",
> > nginx libera quella connessione e quindi diritta verso quel processo la
> > prossima chiamata, ma il processo di fatto è occupato.
> >
> > 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.
> > 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)
> 
> Provate a ridurre a 3 secondi il proxy_connect_timeout di nginx, e'
> probabile che abbiate sempre almeno uno slot listen_queue libero anche se
> lo avete impostato a 1/0. In questo modo se la connessione non completa in
> 3 secondi, nginx considera il peer morto (e passa a quello dopo se lo
> avete configurato a dovere)

nessun cambiamento. Il proxy_connect_timeout pare proprio ignorato. 
questa la conf:

server {
    listen 80;
    server_name ngtest;
    location / {
        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;
        proxy_connect_timeout 3s;
        proxy_pass http://produzione;
    }
}

> > Credo di capire che vengono descritte più opzioni di configurazione: con i
> > greenlet ed una programmazione asincrona o con processi tornado
> > indipendenti.
> 
> guarda terrei questo approccio proprio come ultima spiaggia (e
> probabilmente e' piu' semplice modificare tornado) se la soluzione sopra
> non dovesse funzionare

ecco appunto...
Il primo punto: capisco correttamente che la conf è quella descritta nel
capitoletto "Binding and listening with Tornado"?

Nella mail precedente scrivevi:

> L'approccio migliore (o meglio diciamo quello risolutivo) e' che i
> processi usino lo stesso socket, puoi provare il plugin tornado di uWSGI:

ora la dici "ultima spiaggia". come mai?


sandro
*:-)