Re: [Python] web: sync vs. async

[Daniele Varrazzo]

On Mon, 5 Dec 2011 01:11:22 +0100, Alessandro Dentella wrote:

Grazie Daniele per i molti stimoli, ma vorrei capire meglio...

On Fri, Dec 02, 2011 at 08:44:26PM +, Daniele Varrazzo wrote:

>Comincerei a pensare di usare un server non bloccante (e magari le
>greenlet per avere una API familiare) *solo* se l'applicazione deve
>scalare su migliaia di richieste ed è fondamentale non sprecare
>risorse
>su processi/threads.

I thread non sono una faccenda di risorse sprecate su Python: sono
una faccenda di lock contention, e scala maledettamente male: nelle
poche decine, anche se la macchina permetterebbe ben altro. Nessuno


Se il problema è la lock contention, non vedo come una soluzione 
asincrona
migliori o scali meglio. Se due chiamate devono contendersi uno 
stesso dato

dovrò sempre attuare le stesse strategie anche in modalità
asincrona. Sbaglio?


Il lock di cui parlo che viene conteso è il gil. Alcuni studi (recenti, 
googlabile) hanno mostrato che una situazione di thread bloccati in io 
con thread impegnati con la CPU l'interprete si comporta peggio di 
quanto sperato. In ambienti asincroni, con i singoli lavoratori 
(greenlet o callback) risvegliati dal kernel quando l'I/O è completo 
l'utilizzo della CPU è ottimale.


Nel caso per cui ho fatto partire questa discussione poi ho 
concorrenza
molto limitata (in pratica solo con chiamate generate dalla stessa 
pagina

web, non da altri utenti)


dei nostri programmi (sia web che altro, ma con necessità di
concorrenza) è "sopravvissuto al proprio successo" senza venire
sbudellato (chi ribasato su greenlet, chi riscritto in erlang...) Il
sito web di cui ho parlato oggi ha pochi clienti ma è molto
cpu-intensive e nei giorni di maggiore attività non reggeva 80
clienti connessi prima di splittarlo.

Il problema di Alessandro non è quello di scalare: ha verificato che
la sua macchina è praticamente inattiva per tutto il tempo. Se
risolve il problema del database che lo blocca dovrebbe stare a
cavallo. Poi non è che si sia prodigato in dettagli: magari il
blocco è nel db che offre poche connessioni, non si sa se il db sia
sulla stessa macchina... un po' di lavoro deve farlo anche lui, non
possiamo mica debuggare con la telepatia, no? :) Magari quella cosa
di psycopg + async funziona bene: in fondo quella di twisted pare
vada. E non lo costringerebbe a scrivere il programma da zero.


La soluzione che hai indicato -il modulo momoko- è interessante ma se 
non
capisco male mi costringe comunque a riscrivere tutto. Come ho 
scritto,
l'applicazione al momento usa intensamente SqlAlchemy, non 
direttamente
psycopg2. Il modulo momoko prevede che uno scriva le SQL dirette, non 
che

passi da un ORM. Non mi pare [1che Mike Bayer abbia progetti di
avventurarsi in una versione asincrona di SqlAlchemy.


Per quello no, non ci puoi fare niente. Mi dispiace, ma l'idea è 
sbagliata dalll'inizio. Se il programma è asincrono/callback, NON puoi 
usare funzioni bloccanti. Non puoi farlo in twisted e non puoi farlo in 
tornado. Grazie ai wrapper asincroni puoi usare psycopg, ma perdi 
l'interfaccia dbapi, e di conseguenza tutto quello che la utilizza: 
sqlalchemy, django orm ecc. L'unico modo che io conosca di avere psycopg 
in dbapi asincrono è coi greenlet. Credo sia un disclaimer grande e 
grosso in tornado: tutto quello che blocca dev'essere in una callback: 
se non c'è sono dei criminali :-) Non è che tornado sia meglio di 
twisted da questo punto di vista.



--
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] web: sync vs. async

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/12/2011 01:11, Alessandro Dentella ha scritto:
> [...]
> La soluzione che hai indicato -il modulo momoko- è interessante ma se non
> capisco male mi costringe comunque a riscrivere tutto. Come ho scritto,
> l'applicazione al momento usa intensamente SqlAlchemy, non direttamente
> psycopg2. Il modulo momoko prevede che uno scriva le SQL dirette, non che
> passi da un ORM. Non mi pare [1] che Mike Bayer abbia progetti di
> avventurarsi in una versione asincrona di SqlAlchemy.
> 

Usando greenlet, dovrebbe essere possibile scrivere un engine custom per
SQLAlchemy che usa l'estensione asincrona di psycopg2.
La cosa più complessa è il pooling delle connessioni.

Il vantaggio di greenlet (ed il motivo per cui molti ci vanno dietro) è
che non devi cambiare l'API della tua applicazione.


> [...]


Ciao  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7cpikACgkQscQJ24LbaUQSVwCgjAYCYImgmzzLZ/TK4MXK7yCJ
7jgAni5YJGFfLRX5EzVpiIJW3BX3XKfh
=+Vci
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] web: sync vs. async

[Daniele Varrazzo]

On Mon, 05 Dec 2011 12:08:25 +0100, Manlio Perillo wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/12/2011 01:11, Alessandro Dentella ha scritto:

[...]
La soluzione che hai indicato -il modulo momoko- è interessante ma 
se non
capisco male mi costringe comunque a riscrivere tutto. Come ho 
scritto,
l'applicazione al momento usa intensamente SqlAlchemy, non 
direttamente
psycopg2. Il modulo momoko prevede che uno scriva le SQL dirette, 
non che

passi da un ORM. Non mi pare [1] che Mike Bayer abbia progetti di
avventurarsi in una versione asincrona di SqlAlchemy.



Usando greenlet, dovrebbe essere possibile scrivere un engine custom 
per

SQLAlchemy che usa l'estensione asincrona di psycopg2.
La cosa più complessa è il pooling delle connessioni.

Il vantaggio di greenlet (ed il motivo per cui molti ci vanno dietro) 
è

che non devi cambiare l'API della tua applicazione.


No, è anche più facile di così: basta registrare l'hook in 
set_esit_callback in psycopg e i green thread funzionano esattamente 
come i thread normali anche in psycopg, incluso django, sqlalchemy ecc.



--
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Alessandro Agosto]

Non mi piace l'idea di riesumare questo thread (ma chi voglio prendere in
giro, manco da un pezzo sulla lista, mi piace riesumare thread), ma...
voglio condividere la mia esperienza nel modo più oggettivo possibile
(tolto il fatto che Python rules è perfettamente un dato oggettivo):

2 mesi per sviluppare un CRM, 2 settimane spese imparando cake e symfony
per poi scontrarmi contro la gestione ACL.
Il software veniva deriso dal mio collaboratore (sviluppatore .net, non ha
molto da ridere, ma era PHP, ci stava).
Il software sarebbe dovuto comunque passare a python (sono il cto aziendale
e ho libertà di scelta sulle tecnologie da usare) ma non avevo tempo di
svilupparlo in prima persona e l'altro programmatore non conosceva Python.
Dopo tre settimane estenuanti di test e problemi, dovendo studiare per
altro una documentazione di due fw che non conoscevo ho pensato di fare un
test da solo con Django... un pomeriggio ed avevo tutto quello che sui due
fw sopra citati non eravamo riusciti a fare (gestione utenti, gruppi,
permessi). Nessun problema.
2 ore spese a spiegare a grandi linee all'altro programmatore come funziona
il tutto -passandogli la meravigliosa doc di django- et voilà.
Nessuna critica, anzi...
Abbiamo realizzato 1/5 del progetto in 2 giorni di lavoro. Se si procede
cosi il software sarà finito con 2 settimane di anticipo, considerando le
altre 2 e mezze perse appresso a PHP... ci avremmo impiegato un mese
(calcolando tutto quello che ruota attorno a parte la programmazione).

Se Python da se non convince per qualche motivo, i danari risparmiati a me
sembrano un motivo in più per usare questo magnificamente unico linguaggio
:-P

Ne approfitto, ot per ot, per mettervi al corrente di un link
meraviglioso!
50 citazioni che addobberanno ogni dove nella mia quotidianità (vabbè, per
adesso mi basta avere il bookmark).

Il giorno 26 novembre 2011 07:59, Carlos Catucci
ha scritto:

> lo diamo per scontato? con che percentuale di sconto? o sono saldi?
>
> Carlos
> Il giorno 25/nov/2011 23.21, "Marco Beri"  ha
> scritto:
>
>> 2011/11/25 Carlo Miron 
>>
>> Zitto, Cuffiato™. Non sapresti nemmeno chi e` teknico, se non fosse per
>>> me.
>>
>>
>> Stiamo dando per scontato che ti dovrei ringraziare per questo, giusto?
>>
>> :-P
>>
>>
>> ___
>> Python mailing list
>> Python@lists.python.it
>> http://lists.python.it/mailman/listinfo/python
>>
>>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[enrico franchi]

2011/12/6 Alessandro Agosto 

>
> 2 mesi per sviluppare un CRM, 2 settimane spese imparando cake e symfony
> per poi scontrarmi contro la gestione ACL.
> Il software veniva deriso dal mio collaboratore (sviluppatore .net, non ha
> molto da ridere, ma era PHP, ci stava).
> Il software sarebbe dovuto comunque passare a python (sono il cto
> aziendale e ho libertà di scelta sulle tecnologie da usare) ma non avevo
> tempo di svilupparlo in prima persona e l'altro programmatore non conosceva
> Python. Dopo tre settimane estenuanti di test e problemi, dovendo studiare
> per altro una documentazione di due fw che non conoscevo ho pensato di fare
> un test da solo con Django... un pomeriggio ed avevo tutto quello che sui
> due fw sopra citati non eravamo riusciti a fare (gestione utenti, gruppi,
> permessi). Nessun problema.
> 2 ore spese a spiegare a grandi linee all'altro programmatore come
> funziona il tutto -passandogli la meravigliosa doc di django- et voilà.
> Nessuna critica, anzi...
> Abbiamo realizzato 1/5 del progetto in 2 giorni di lavoro. Se si procede
> cosi il software sarà finito con 2 settimane di anticipo, considerando le
> altre 2 e mezze perse appresso a PHP... ci avremmo impiegato un mese
> (calcolando tutto quello che ruota attorno a parte la programmazione).
>
>
Questa me la salvo per linkarla alla prossima advocacy... ;)


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python