Re: [Python] Dove risiede l'eseguibile?
2013/12/30 Gabriele Battaglia > Et voilà, per fortuna che c’è ancora qualche posto al mondo, in cui non > servono i $. Mitica! Spero che quelle PERL* di programmatori che lo usano non se ne abbiano troppo a male * PHP Exalted Retired Loser? Probably Elevated Reversed Lounger? Carlos -- "Somos los que amasan, sin embargo no tenemos pan, somos los que cavan el carbón, sin embargo tenemos frío somos los que no tienen nada, y estamos viniendo a tomar el mundo." Tassos Livaditis (Poeta greco, 1922, 1988) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Deploy con nginx e proxy_pass
> 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
Re: [Python] Deploy con nginx e proxy_pass
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. sandro *:-) PS: ho letto la documentazione del plugin di tornado di uWSGI, mi pare relativamete semplice ma non ho ancora avuto tempo di provarla ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Semantica del modulo multiprocessing.
On 30/12/2013 16:37, Walter Valenti wrote: Mettiamo che abbia una situazione del genere: ### from multiprocessing import Process, Manager class T1(object): def __init__(self): print "init..." self.run() def run(self): print "run",str(os.getpid()) Sarò io che magari non comprendo il "grande disegno", ma fare: def t1(): print "run", os.getpid() usando una semplice funzione, non andava bene? :) class T2(object): p = Process(target=T1) p.start() p.join() T2() ### Come faccio in questo caso a condividere una variabile tra il processo padre e i figlio? Memoria condivisa, come spiegato nella documentazione. Se uso il Manager ho il problema che le due classi hanno ognuna il proprio namespace. Certo, è il motivo per cui stai usando i processi, no? Altrimenti usa i thread. Ho provato ad usare BaseManager, per crearmi il Manager ad Hoc. In questo caso ha funzionato, ma la cosa è bloccante. Se il processo figlio esegue un loop, il padre rimane in attesa bloccato. Come lo stai usando? Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Semantica del modulo multiprocessing.
Mettiamo che abbia una situazione del genere: ### from multiprocessing import Process, Manager class T1(object): def __init__(self): print "init..." self.run() def run(self): print "run",str(os.getpid()) class T2(object): p = Process(target=T1) p.start() p.join() T2() ### Come faccio in questo caso a condividere una variabile tra il processo padre e i figlio? Se uso il Manager ho il problema che le due classi hanno ognuna il proprio namespace. Ho provato ad usare BaseManager, per crearmi il Manager ad Hoc. In questo caso ha funzionato, ma la cosa è bloccante. Se il processo figlio esegue un loop, il padre rimane in attesa bloccato. Walter -- Per favore non inviatemi allegati in formato MS Office. Utilizza alternativamente documenti in formato OpenDocument. http://oinophilos.blogspot.com/ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dove risiede l'eseguibile?
Il giorno 30/dic/2013, alle ore 15:50, Simone Federici ha scritto: > Ps: I dollari non servono sulla shell. GB: Et voilà, per fortuna che c’è ancora qualche posto al mondo, in cui non servono i $. Risultato: /Library/Frameworks/Python.framework/Versions/2.7/bin/python Che, tanto per andare sul tranquillo, è ancora diversa dalle altre che avevo viste. :)___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dove risiede l'eseguibile?
2013/12/30 Gabriele Battaglia > > Il giorno 30/dic/2013, alle ore 15:50, Simone Federici < > s.feder...@gmail.com> ha scritto: > > Ps: I dollari non servono sulla shell. > > GB: Et voilà, per fortuna che c’è ancora qualche posto al mondo, in cui > non servono i $. > Siete due geni. Tu per la battuta, Simone per aver capito l'errore. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dove risiede l'eseguibile?
Ps: I dollari non servono sulla shell. -- Simone Federici Software Craftsman XP, Agile, Scrum, Kanban Quality, performance & security Explicit is better than implicit. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dove risiede l'eseguibile?
Il giorno 30/dic/2013, alle ore 14:00, Carlos Catucci ha scritto: > Ho aperto il terminale e digitato al prompt: > > $ which python > > Su terminale MAC? Che versione di OS? Da me va. > > Carlos. GB: Sì, terminale Mac OS 10.9 Mavericks. Command not found. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dove risiede l'eseguibile?
2013/12/30 Gabriele Battaglia > Il comando che mi suggerisci da me non funziona: “Command not found”. > > Ho aperto il terminale e digitato al prompt: > > $ which python > Su terminale MAC? Che versione di OS? Da me va. Carlos -- "Somos los que amasan, sin embargo no tenemos pan, somos los que cavan el carbón, sin embargo tenemos frío somos los que no tienen nada, y estamos viniendo a tomar el mundo." Tassos Livaditis (Poeta greco, 1922, 1988) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dove risiede l'eseguibile?
Il giorno 30/dic/2013, alle ore 08:23, Simone Dalla ha scritto: > Io sviluppo in Python su Mac (ora all'ultima versione 10.9) da parecchio > tempo. Se vuoi verificare i path di python installati di default, di cui > dicevi, lancia da terminale il comando > > $ which python (darà un'ouptut del tipo "/usr/bin/python") > GB: Ciao Simone, grazie per le info e piacere di leggerti. Andiamo per gradi, poi commenterò anche le altre cose che mi scrivi sugli editors. Qui andiamo un pelo fuori tema, non so se sia meglio per gli altri, che continuiamo OffList. Il comando che mi suggerisci da me non funziona: “Command not found”. Ho aperto il terminale e digitato al prompt: $ which python Alla prossima. GB.___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dove risiede l'eseguibile?
Enrico, penso tu mi abbia fatto scoprire un editor utile e finalmente accessibile: TextMate 2.0, Grazie. GB. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
