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