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
*:-)
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
