Re: [Python] Python e DAS/NAS/SAN

[Balan Victor]

ho provato ma c'è qualcosa che non mi torna. Faccio questo commando:

>>> disk_usage('C:')
usage(total=2962784256L, used=-1328619520L, free=4291403776L)

come gli interpreto i valori? sono byte?

Il giorno 12 dicembre 2011 20:27, Balan Victor  ha
scritto:

> ma una nas non è proprio un volume di reteadesso ho provato e sui
> volumi di rete funziona domani provo anche sulla nas.
> grazie.
>
> Il giorno 12 dicembre 2011 13:35, Giampaolo Rodolà ha 
> scritto:
>
> Il 12 dicembre 2011 12:45, Balan Victor  ha
>> scritto:
>> > Ciao,
>> > ho un server su cui lancio dei script python, da questo server accedo
>> anche
>> > a una NAS tramite percorso UNC. Esiste un modulo di python che mi
>> permette
>> > di fare operazioni su questa NAS?? per esempio vedere lo spazio disco,
>> > contare il numero di file ecc.
>> > Grazie.
>>
>> Non so quale sia il comportamento su volumi di rete, ma puoi provare
>> ad utilizzare questa recipe e vedere che succede:
>> http://code.activestate.com/recipes/577972-disk-usage/
>>
>>
>> --- Giampaolo
>> http://code.google.com/p/pyftpdlib/
>> http://code.google.com/p/psutil/
>> ___
>> 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] web2py: lo conoscete -> sessioni su db

[Daniele Varrazzo]

On Tue, 13 Dec 2011 00:42:59 +0100, Alessandro Dentella wrote:

Comincio dal fondo, forse risulta più chiaro il tutto.

On Mon, Dec 12, 2011 at 10:13:48PM +, Daniele Varrazzo wrote:

A proposito, poi com'è andata con la storia di tornado e psycopg?


bene! con 10 processi tornado i tempi si sono azzerati


Ah, la soluzione "se va bene a FriendFeed va bene anche a me" :) ok.



E perché vorresti impedire di leggere? Uno fa tanto per progettare
un database che consenta letture e scritture concorrenti e tu infili
gli un ombrello nella ruota davanti? :)


come la metti giù dura! Quelli che fanno tutta quella fatica a 
progettare i
db hanno anche pensato alla utilità del "SELECT FOR UPDATE", quelli 
di
postgresql poi l'hanno fatto selettivo al singolo record, ed in 
lettura mica
mi si blocca se non uso "FOR UPDATE". L'update della sessione lo 
blocco dove

mi serve!


Sì, ma il blocco serve a coordinare la scrittura consistente di diversi 
record: usare il lock per serializzare nel tempo è un noto anti-pattern 
sui database. Nel tuo caso, siccome vuoi applicarlo alle sessioni, il 
lock viene preso molto presto e rilasciato molto tardi nel tempo di vita 
di una richiesta, quindi stai effettivamente serializzando tutte le 
richieste di un utente, come tutte le chiamate ajax di una pagina.


Quello che vorrei farti capire, ma non sono bravo è che c'è qualcosa 
che *puzza*. Avete un ambiente concorrente per definizione (diversi 
utenti contemporaneamente, diverse richieste per utente via ajax). Avete 
un framework concorrente (lasciamo perdere che è usato male: più viene 
usato meglio più lo diventa). Avete un database che supporta la 
concorrenza... e qual'è il problema: che è troppo concorrente?!?! E lo 
volete serializzare?


Allora, non vedi che in questo disegno qualcosa non va?

Da quello che descrivi, avete stato in memoria, stato in postgres, 
stato in redis, più le sessioni, e tutte devono essere coordinate... Mi 
sembra un grosso problema farlo. Perchè tutta questa isteria?


Quanta roba ci dovete scrivere nelle sessioni, che le richieste ajax si 
inciampano a vicenda? Nella sessione scrivici l'id dell'utente e basta, 
lo scrivi al login e lo usi solo per leggere. Mi sembra di capire che 
ogni richiesta ci scriva qualcosa: perché lo scrivi nella sessione e non 
lo tieni in memoria o in redis?




Controindicazioni dei lock espliciti? Quante ne vuoi. Non è una


Dai dammene qualcuna di convincente...


Googla "database ipc antipattern".

Diciamo che la prevedo così: se sei fortunato, noti immediatamente un 
rallentamento di prestazioni dovuto alla serializzazione di ogni 
richiesta. Se non lo sei, la serializzazione resta latente: a un certo 
punto ci sarà un cambiamento non collegato nelle richieste al database 
che litigherà coi lock presi sulla sessione e vi trovate con qualcosa 
che non cammina più, e se non avete sviluppato strategie di debug dei 
lock sul database, se non vi ricordate nemmeno che avete messo i lock 
sulle sessioni... in bocca al lupo a capire perché.


Se hai richieste concorrenti che devono essere processate in serie, 
fallo in memoria, visto che stai già pagando il prezzo di avere session 
affinity e quindi una certa garanzia che tutte le rihcieste l'utente 
vadano sullo stesso server. Voi avete in pratica un programma web che 
dialoga con un application server: ormai, tieni la consistenza nel 
server. Almeno serializzi solo quello che ti serve, non tutte le 
richieste che mai passeranno per il web server e che non hanno bisogno 
di serializzazione. Altrimenti serializzi anche servire file statici o 
cazzate del genere. Questo è un esempio: immagino i file statici siano 
serviti dal web server, ma qualcos'altro che non necessita di essere 
serializzato, che non fa parte dello spreadsheet, di sicuro ci sarà, e 
se serializzi le sessioni anche quello prende il suo share di tempo 
esclusivo.



--
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] Python e DAS/NAS/SAN

[Marco Beri]

2011/12/13 Balan Victor 

> ho provato ma c'è qualcosa che non mi torna. Faccio questo commando:
> >>> disk_usage('C:')
> usage(total=2962784256L, used=-1328619520L, free=4291403776L)
> come gli interpreto i valori? sono byte?
>

Guarda il codice:


st = os.statvfs(path)
free = st.f_bavail * st.f_frsize
total = st.f_blocks * st.f_frsize
used = (st.f_blocks - st.f_bfree) * st.f_frsize
return _ntuple_diskusage(total, used, free)


E guarda la documentazione: http://docs.python.org/library/statvfs.html

Ciao.
Marco.

-- 
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] web2py: lo conoscete -> sessioni su db

[Alessandro Dentella]

On Tue, Dec 13, 2011 at 10:26:57AM +, Daniele Varrazzo wrote:
> On Tue, 13 Dec 2011 00:42:59 +0100, Alessandro Dentella wrote:
> >Comincio dal fondo, forse risulta più chiaro il tutto.
> >
> >On Mon, Dec 12, 2011 at 10:13:48PM +, Daniele Varrazzo wrote:
> >>A proposito, poi com'è andata con la storia di tornado e psycopg?
> >
> >bene! con 10 processi tornado i tempi si sono azzerati
> 
> Ah, la soluzione "se va bene a FriendFeed va bene anche a me" :) ok.
> 
> 
> >>E perché vorresti impedire di leggere? Uno fa tanto per progettare
> >>un database che consenta letture e scritture concorrenti e tu infili
> >>gli un ombrello nella ruota davanti? :)
> >
> >come la metti giù dura! Quelli che fanno tutta quella fatica a
> >progettare i
> >db hanno anche pensato alla utilità del "SELECT FOR UPDATE",
> >quelli di
> >postgresql poi l'hanno fatto selettivo al singolo record, ed in
> >lettura mica
> >mi si blocca se non uso "FOR UPDATE". L'update della sessione lo
> >blocco dove
> >mi serve!
> 
> Sì, ma il blocco serve a coordinare la scrittura consistente di
> diversi record: usare il lock per serializzare nel tempo è un noto
> anti-pattern sui database. Nel tuo caso, siccome vuoi applicarlo
> alle sessioni, il lock viene preso molto presto e rilasciato molto
> tardi nel tempo di vita di una richiesta, quindi stai effettivamente
> serializzando tutte le richieste di un utente, come tutte le
> chiamate ajax di una pagina.
> 
> Quello che vorrei farti capire, ma non sono bravo è che c'è qualcosa
> che *puzza*. Avete un ambiente concorrente per definizione (diversi
> utenti contemporaneamente, diverse richieste per utente via ajax).
> Avete un framework concorrente (lasciamo perdere che è usato male:
> più viene usato meglio più lo diventa). Avete un database che
> supporta la concorrenza... e qual'è il problema: che è troppo
> concorrente?!?! E lo volete serializzare?
> 
> Allora, non vedi che in questo disegno qualcosa non va?
> 
> Da quello che descrivi, avete stato in memoria, stato in postgres,
> stato in redis, più le sessioni, e tutte devono essere coordinate...
> Mi sembra un grosso problema farlo. Perchè tutta questa isteria?

Non sono stati differenti, è sempre la stessa cosa (la sessione) che viene
memorizzata o in ram o in redis o in postgres: voglio scegliere la soluzione
più idonea per quel particolare tipo di applicazione. 

Lo stato in memoria non mi piace: non posso riavviare il server con
serenità. Eliminata questa richiesta non ho neanche più la necessità della
session affinity. 

Redis è stato introdotto per affrontare il problema di rallentamenti come
storage per le sessioni ma come errata diagnosi, ora non è più necessario
anche perché dalle mie prove (assolutamente primitive) non si guadagna nulla
di interessante rispetto al db. E la velocità non è il problema in ogni caso.

> Quanta roba ci dovete scrivere nelle sessioni, che le richieste ajax
> si inciampano a vicenda? Nella sessione scrivici l'id dell'utente e
> basta, lo scrivi al login e lo usi solo per leggere. Mi sembra di
> capire che ogni richiesta ci scriva qualcosa: perché lo scrivi nella
> sessione e non lo tieni in memoria o in redis?

che vantaggio mi darebbe tenerlo in redis?

> Se hai richieste concorrenti che devono essere processate in serie,
> fallo in memoria, visto che stai già pagando il prezzo di avere
> session affinity e quindi una certa garanzia che tutte le rihcieste
> l'utente vadano sullo stesso server. Voi avete in pratica un
> programma web che dialoga con un application server: ormai, tieni la
> consistenza nel server. Almeno serializzi solo quello che ti serve,
> non tutte le richieste che mai passeranno per il web server e che
> non hanno bisogno di serializzazione. Altrimenti serializzi anche
> servire file statici o cazzate del genere. Questo è un esempio:
> immagino i file statici siano serviti dal web server, ma
> qualcos'altro che non necessita di essere serializzato, che non fa
> parte dello spreadsheet, di sicuro ci sarà, e se serializzi le
> sessioni anche quello prende il suo share di tempo esclusivo.

ma anche se prendo le sessioni da db posso serializzare solo quello che mi
serve. Al di fuori della pagina che simula il foglio elettronico non ho
alcun bisogno di serializzare e lo evito.

> session affinity e quindi una certa garanzia che tutte le rihcieste

tu qui dici una *certa* garanzia. Non so se esprime il fatto che la session
affinity possa non essere garantita, io uso ip_hash di nginix ora...

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

Re: [Python] web2py: lo conoscete -> sessioni su db

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 13/12/2011 14:38, Alessandro Dentella ha scritto:
> [...]
> Non sono stati differenti, è sempre la stessa cosa (la sessione) che viene
> memorizzata o in ram o in redis o in postgres: voglio scegliere la soluzione
> più idonea per quel particolare tipo di applicazione. 
> 
> Lo stato in memoria non mi piace: non posso riavviare il server con
> serenità. Eliminata questa richiesta non ho neanche più la necessità della
> session affinity. 
> 
> Redis è stato introdotto per affrontare il problema di rallentamenti come
> storage per le sessioni ma come errata diagnosi, ora non è più necessario
> anche perché dalle mie prove (assolutamente primitive) non si guadagna nulla
> di interessante rispetto al db.

Davvero?
Mi aspetto che, per delle semplici sessioni (storage key-value) redis
sia significativamente più veloce di un database relazionale.

Magari sopravvaluto Redis, o sottovaluto PostgreSQL, o semplicemente per
i tuoi numeri non si notano differenze.

> E la velocità non è il problema in ogni caso.
> 
>> Quanta roba ci dovete scrivere nelle sessioni, che le richieste ajax
>> si inciampano a vicenda? Nella sessione scrivici l'id dell'utente e
>> basta, lo scrivi al login e lo usi solo per leggere. Mi sembra di
>> capire che ogni richiesta ci scriva qualcosa: perché lo scrivi nella
>> sessione e non lo tieni in memoria o in redis?
> 
> che vantaggio mi darebbe tenerlo in redis?
> 

Accesso ragionevolmente efficiente ed atomico + consistenza dei dati.
Inoltre non hai il problema della session affinity.

Ti resta da decidere se usare PostgreSQL o Redis.
Le sessioni come sono strutturate?

> [...]


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

iEYEARECAAYFAk7nXlEACgkQscQJ24LbaUQAAwCdFl3tzNCaAUYnablnMZT7uOcS
140AoJml43ZlunOce2ENst6q0Gr1uEuJ
=9YGp
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 11/12/2011 23:05, enrico franchi ha scritto:
> 
> 
> 2011/12/11 Manlio Perillo  >
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Il 07/12/2011 18:17, Giampaolo Rodolà ha scritto:
> > [...]
> >> Non devi neanche gestire le eccezioni, è chiaro che è molto
> implicito e che
> >> sa un po' di quick and dirty, ma
> >>  1) in alcuni casi non serve
> >>  2) e se serve allora hai sbagliato linguaggio :-(
> >
> > Scusa ma con tutta la buona volontà non riesco a digerire una cosa di
> > questo tipo:
> >
> > php > print '3viso'+2;
> > 5
> >
> 
> Scusa, ma di cosa vi scandalizzate?
> Anche Common Lisp lo permette, almeno 10 anni prima di PHP:
> 
> 
> Dimmi che e' una battuta che io non colgo... 

Certo che lo era, non si notava? ;-)

> Comunque, bella forza, gli hai esplicitamente detto di farlo!
> 

Infatti.

> In Python non mi viene in mente quale sarebbe il metodo piu' rapido.
>

A me al momento non viene in mente proprio nessun metodo per farlo.

> [...]


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

iEYEARECAAYFAk7nXsQACgkQscQJ24LbaUQpBQCfYw0zFutXYpGDSjSTHcpANuPT
15QAnjNKGM0xTWiWzwosZGBQnV83s1PY
=ECUP
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Tracciare punti (input tabella excel)

[Francesco Bonanno]

Salve, devo interpretare  a video dei dati provenienti da una tabella di 
coordinate del tipo gradi minuti secondi per tracciare dei movimenti, e 
sovrapporli ad una mappa.

Sapete darmi una dritta?
Grazie
Franky
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Tracciare punti (input tabella excel)

[Marco Beri]

2011/12/13 Francesco Bonanno 

> Salve, devo interpretare  a video dei dati provenienti da una tabella di
> coordinate del tipo gradi minuti secondi per tracciare dei movimenti, e
> sovrapporli ad una mappa.
> Sapete darmi una dritta?
>

Sì: spiegati meglio :-))

Ciao.
Marco.

-- 
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] [OT]: PHP critique [ERA] Re: Python e html

[Carlo Miron]

2011/12/13 Manlio Perillo :
> Il 11/12/2011 23:05, enrico franchi ha scritto:
>> 2011/12/11 Manlio Perillo >     Scusa, ma di cosa vi scandalizzate?
>>     Anche Common Lisp lo permette, almeno 10 anni prima di PHP:
>> Dimmi che e' una battuta che io non colgo...
> Certo che lo era, non si notava? ;-)

Manlio, avevi gia` fatto una battuta, quest'anno. Contieniti, per favore.
©
-- 
Carlo Miron
Restrain Yourself Solution Architect™
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

> Anche Common Lisp lo permette, almeno 10 anni prima di PHP:

> > Dimmi che e' una battuta che io non colgo...
>


> Certo che lo era, non si notava? ;-)
>

Dopo dovevi aggiungere Basinga! ;)


> A me al momento non viene in mente proprio nessun metodo per farlo.
>

A me non viene in mente un motivo valido per volerlo fare. Sara' che non ho
mai provato LSD o Peyote.

Carlos
-- 
If you have no voice, SCREAM! If you have no legs, RUN! If you have no
hope, INVENT!
___
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/13 Manlio Perillo 

>
> > Dimmi che e' una battuta che io non colgo...
> Certo che lo era, non si notava? ;-)


Uff... ieri stavo guardando functionaljava. Ho letto "funtore applicativo"
e tac, ho perso la capacita' di capire le battute per 24h. :(


> A me al momento non viene in mente proprio nessun metodo per farlo.


 Il problema principale e' che non ti fanno fare monkey patching degli
interi (o delle stringhe)...
Se no sarebbe stato banale.

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

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

[Marco Mariani]

2011/12/13 enrico franchi 

A me al momento non viene in mente proprio nessun metodo per farlo.
>
>
>  Il problema principale e' che non ti fanno fare monkey patching degli
> interi (o delle stringhe)...
>
>
Questo e' un uso della parola "problema" che ancora non conoscevo.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Python e DAS/NAS/SAN

[Giampaolo Rodolà]

Il 13 dicembre 2011 10:04, Balan Victor  ha scritto:
> ho provato ma c'è qualcosa che non mi torna. Faccio questo commando:
>
 disk_usage('C:')
> usage(total=2962784256L, used=-1328619520L, free=4291403776L)
>
> come gli interpreto i valori? sono byte?

Si (c'è scritto nella docstring).
Come extra, per avere risultati leggibili, puoi usare questo:


def bytes2human(n):
"""
>>> bytes2human(1)
'9.8K'
>>> bytes2human(11221)
'95.4M'
"""
symbols = ('K', 'M', 'G', 'T', 'P', 'E', 'Z', 'Y')
prefix = {}
for i, s in enumerate(symbols):
prefix[s] = 1 << (i+1)*10
for s in reversed(symbols):
if n >= prefix[s]:
value = float(n) / prefix[s]
return '%.1f%s' % (value, s)
 return "0B"


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Python e DAS/NAS/SAN

[Carlo Miron]

2011/12/13 Giampaolo Rodolà :
> Come extra, per avere risultati leggibili, puoi usare questo:
>
> def bytes2human(n):
>    """
>    >>> bytes2human(1)
>    '9.8K'
>    >>> bytes2human(11221)
>    '95.4M'
>    """
>    symbols = ('K', 'M', 'G', 'T', 'P', 'E', 'Z', 'Y')
>    prefix = {}
>    for i, s in enumerate(symbols):
>        prefix[s] = 1 << (i+1)*10
>    for s in reversed(symbols):
>        if n >= prefix[s]:
>            value = float(n) / prefix[s]
>            return '%.1f%s' % (value, s)
>     return "0B"

C'e` un IndentationError nell'ultima riga :P
Inoltre i simboli corretti dovrebbero essere ('KiB', 'MiB', 'GiB',
'TiB', 'PiB', 'EiB', 'ZiB', 'YiB').
Infine, restituisce sempre "0B" per ogni valore di n < 1024.

Cheese,
©
-- 
Carlo Miron
Precisino Rompiballe Solution Architect™
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] web2py: lo conoscete -> sessioni su db

[Alessandro Dentella]

On Tue, Dec 13, 2011 at 03:16:49PM +0100, Manlio Perillo wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Il 13/12/2011 14:38, Alessandro Dentella ha scritto:
> > [...]
> > Non sono stati differenti, è sempre la stessa cosa (la sessione) che viene
> > memorizzata o in ram o in redis o in postgres: voglio scegliere la soluzione
> > più idonea per quel particolare tipo di applicazione. 
> > 
> > Lo stato in memoria non mi piace: non posso riavviare il server con
> > serenità. Eliminata questa richiesta non ho neanche più la necessità della
> > session affinity. 
> > 
> > Redis è stato introdotto per affrontare il problema di rallentamenti come
> > storage per le sessioni ma come errata diagnosi, ora non è più necessario
> > anche perché dalle mie prove (assolutamente primitive) non si guadagna nulla
> > di interessante rispetto al db.
> 
> Davvero?
> Mi aspetto che, per delle semplici sessioni (storage key-value) redis
> sia significativamente più veloce di un database relazionale.

Lo è, ma stiamo parlando di numeri molti piccoli per le mie
esigenze. Recuperare una sessione 'media' da pg mi prende 1.0 ms,
recupararla da redis può prendere anche 5/6 volte meno. Se la sessione è
grande l'unpickle prende oltre i 20 ms, quindi l'ottimizzazione non è certo
da cercare in redis ma in una ottimizzazione di ciò che sta nella sessione.

> > E la velocità non è il problema in ogni caso.
> > 
> >> Quanta roba ci dovete scrivere nelle sessioni, che le richieste ajax
> >> si inciampano a vicenda? Nella sessione scrivici l'id dell'utente e
> >> basta, lo scrivi al login e lo usi solo per leggere. Mi sembra di
> >> capire che ogni richiesta ci scriva qualcosa: perché lo scrivi nella
> >> sessione e non lo tieni in memoria o in redis?
> > 
> > che vantaggio mi darebbe tenerlo in redis?
> > 
> 
> Accesso ragionevolmente efficiente ed atomico + consistenza dei dati.
> Inoltre non hai il problema della session affinity.

io intendevo rispetto al db non rispetto alla RAM

> Ti resta da decidere se usare PostgreSQL o Redis.

Esatto, ed io propendo per pg. Prima che Daniele mi massacrasse sulla
questione del "select for update" la preferivo anche per la possibilità di
scegliere che alcune sessioni le prendo garantendo la sequenzialità (quelle
che servono la spreadsheet). Ora ci rifletterò e se anche dovessi scegliere
la strada della perdizione mi sa che non lo dico in lista :-)

> Le sessioni come sono strutturate?

confesso che ne so ancora poco. Ho preso in mano questa situazione da un
paio di settimane ma non a tempo pieno e altre cose hanno reclamato la mia
attenzione. Chiaramente, per i motivi di cui sopra varrà la pena analizzare.

Visto che tu conosci bene nginix, ip_hash è totalmente affidabile per la
session affinity?, abbiamo avuto alcuni comportamenti strani dopo avere
attivato il setup con svariate istanze di tornado su 2 server che si risolvevano
dirottando verso una seconda istanza di nginix con un solo server (e due
tornado) non sono sicuro che fosse un problema di sessioni, ma il tarlo
ce l'ho...

sandro
*:-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Python e DAS/NAS/SAN

[Giampaolo Rodolà]

Il 13 dicembre 2011 18:11, Carlo Miron  ha scritto:
> Inoltre i simboli corretti dovrebbero essere ('KiB', 'MiB', 'GiB',
> 'TiB', 'PiB', 'EiB', 'ZiB', 'YiB').

Personalmente non mi pare di ricordare di averli mai visti
rappresentati in quel modo.

> Infine, restituisce sempre "0B" per ogni valore di n < 1024.

Argh! Hai ragione. =)

--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Python e DAS/NAS/SAN

[Giampaolo Rodolà]

def bytes2human(n):
symbols = ('K', 'M', 'G', 'T')
prefix = {}
for i, s in enumerate(symbols):
prefix[s] = 1 << (i+1)*10
for s in reversed(symbols):
if n >= prefix[s]:
value = float(n) / prefix[s]
return '%.1f%s' % (value, s)
return "%iB" % n

Così dovrebbe essere a posto.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Python e DAS/NAS/SAN

[Marco Beri]

2011/12/13 Giampaolo Rodolà 

> Il 13 dicembre 2011 18:11, Carlo Miron  ha scritto:
> > Inoltre i simboli corretti dovrebbero essere ('KiB', 'MiB', 'GiB',
> > 'TiB', 'PiB', 'EiB', 'ZiB', 'YiB').
>
> Personalmente non mi pare di ricordare di averli mai visti
> rappresentati in quel modo.
>

http://en.wikipedia.org/wiki/Binary_prefix

:-)

Ciao.
Marco.

-- 
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] Python e DAS/NAS/SAN

[Carlo Miron]

2011/12/13 Giampaolo Rodolà :
> Il 13 dicembre 2011 18:11, Carlo Miron  ha scritto:
>> Inoltre i simboli corretti dovrebbero essere ('KiB', 'MiB', 'GiB',
>> 'TiB', 'PiB', 'EiB', 'ZiB', 'YiB').
>
> Personalmente non mi pare di ricordare di averli mai visti
> rappresentati in quel modo.

IEC since 1998, IEEE standard since 2005.


La cosa piu` carina sono i nomi: kibibyte, mebibyte, gibibyte... =D
Ah, e ovviamente il numero dello standard IEEE, che mi ricorda il
floppy del C64 :P
©
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Python e DAS/NAS/SAN

[Giampaolo Rodolà]

Il 13 dicembre 2011 19:19, Carlo Miron  ha scritto:
> IEC since 1998, IEEE standard since 2005.
> 
> 
> La cosa piu` carina sono i nomi: kibibyte, mebibyte, gibibyte... =D
> Ah, e ovviamente il numero dello standard IEEE, che mi ricorda il
> floppy del C64 :P

Ah! Mica lo sapevo...
In effetti ora che guardo transmission li rappresenta in quel modo.
"df -h" no però.

--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] web2py: lo conoscete -> sessioni su db

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 13/12/2011 18:51, Alessandro Dentella ha scritto:
> [...]
>>> Redis è stato introdotto per affrontare il problema di rallentamenti come
>>> storage per le sessioni ma come errata diagnosi, ora non è più necessario
>>> anche perché dalle mie prove (assolutamente primitive) non si guadagna nulla
>>> di interessante rispetto al db.
>>
>> Davvero?
>> Mi aspetto che, per delle semplici sessioni (storage key-value) redis
>> sia significativamente più veloce di un database relazionale.
> 
> Lo è, ma stiamo parlando di numeri molti piccoli per le mie
> esigenze. Recuperare una sessione 'media' da pg mi prende 1.0 ms,
> recupararla da redis può prendere anche 5/6 volte meno. Se la sessione è
> grande l'unpickle prende oltre i 20 ms, quindi l'ottimizzazione non è certo
> da cercare in redis ma in una ottimizzazione di ciò che sta nella sessione.
> 

Valuta anche di testare alternative a pickle.
Ad esempio http://msgpack.org/ (che non ho mai usato, comunque).

> [...]
>>>
>>> che vantaggio mi darebbe tenerlo in redis?
>>>
>>
>> Accesso ragionevolmente efficiente ed atomico + consistenza dei dati.
>> Inoltre non hai il problema della session affinity.
> 
> io intendevo rispetto al db non rispetto alla RAM
> 

Per semplici sessioni è più semplice di un database relazionale, IMHO.
Inoltre:
http://redis.io/topics/transactions

WATCH usa un lock ottimistico, magari può essere una alternativa valida
al problema che devi risolvere (che, devo ammettere, non sono ancora
sicuro di aver capito pienamente).

> [...]
> 
> Visto che tu conosci bene nginix, ip_hash è totalmente affidabile per la
> session affinity?, abbiamo avuto alcuni comportamenti strani dopo avere
> attivato il setup con svariate istanze di tornado su 2 server che si 
> risolvevano
> dirottando verso una seconda istanza di nginix con un solo server (e due
> tornado) non sono sicuro che fosse un problema di sessioni, ma il tarlo
> ce l'ho...
> 

Non sono sicuro di avere capito il setup dei server.

Comunque ip_hash funziona solo se hai *un solo* server Nginx che accetta
tutte le richieste e poi le rigira alle instanze di tornado.

http://wiki.nginx.org/HttpUpstreamModule#ip_hash


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

iEYEARECAAYFAk7noQcACgkQscQJ24LbaURjOgCcDlUyTNmYMy8Vi7ire2c5k0e3
YVMAoJE0BfqHDn7ZP5EDU35Onp0StsTk
=p21v
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] cgi ottimizzati ERA: web: sync vs. async

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 13/12/2011 06:45, Roberto De Ioris ha scritto:
> 
>>
>>
>> Io stavo valutando un altra strada (nel caso in cui non serva un elevato
>> grado di concorrenza): il buon vecchio CGI.
>> Ovviamente non CGI normale, ma fare in modo che l'interprete Python sia
>> embedato nel server (e pre-caricare in memoria quanto più possibile
>> specialmente se read-only) e poi fare un fork + Python exec.
>>
>> Rispetto ad un CGI normale (fork + sys exec) mi aspetto un miglioramento
>> significativo, anche grazie al copy-on-write.
>>
>>
> 
> Ho trovato un po' di tempo per tentare questo approccio:
> 
> http://projects.unbit.it/uwsgi/wiki/CGI#Example10:optimizingCGIs
> 
> effettivamente il guadagno prestazionale c'e', e anche tanto.
> 

Grazie per la conferma!

> [...]
>
> Il "problema", e' che infilare i CGI in nginx (intendo senza passare per
> uWSGI) e' fuori discussione (almeno per linux) poiche' tutte le wait()
> sono bloccanti e anche usando WNOHANG sarebbe richiesto uno sforzo non
> indifferente al core di nginx (che dovrebbe chiamare waitpid() a
> intervalli regolari per vedere se qualcosa e' cambiato). Nei BSD sarebbe
> molto piu' facile, perche' kqueue() puo' rimanere in attesa di un processo
> oltre che di un file descriptor (bellissimo).
> 

Il "trucco" è usare un socket UNIX domain bidirezionale, invece di due pipe.
In questo modo per Nginx la comunicazione con il processo CGI dovrebbe
essere analoga a quella con un client remoto.
In particolare non dovrebbe mai essere necessario chiamare waitpid.


Ciao  Manlio

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

iEYEARECAAYFAk7nu+8ACgkQscQJ24LbaURSQQCfXfDvuTer/IBRro1wsFE82qsO
FKUAniwhjPicHKRYss4TCdR8RbuWRPpU
=6awY
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Daniele Tricoli]

On Tuesday 13 December 2011 16:06:44 enrico franchi wrote:
>  Il problema principale e' che non ti fanno fare monkey patching degli
> interi (o delle stringhe)...
> Se no sarebbe stato banale.

E già, ma io personalmente non ne sono dispiaciuto :)

Quando ho scritto che si può ottenere lo stesso risultato dell'esempio di 
Manlio, in una sessione interattiva dell'interprete, ovviamente intendevo 
semplicemente dire che si può "barare" affinché l'interprete faccia 
apparire lo stesso risultato del 2 + '3viso' di PHP.

Quello che mi era venuto in mente, senza testarlo, era una cosa del genere. 
Sottolineo che non è semanticamente la stessa cosa che ha fatto Manlio in 
Lisp, è solo un trucco :)

Ah e tra l'altro solo per Unix visto che sto usando readline ;)

Ecco cosa mi era passato per la testa:

re_numbers = numbers = re.compile(r'(\d+)+')
re_operators = re.compile(r'[+\-*/]+')

def trick(t, v, tb):
if isinstance(v, TypeError):
line = readline.get_history_item(
   readline.get_current_history_length())

numbers = [int(n) for n in re_numbers.findall(line)]
operators = re_operators.findall(line)
# Da qui in poi è banale

Ovviamente usando:
sys.excepthook = trick

Ripeto, è soltanto un modo per far *apparire* lo stesso risultato: non è il 
porting in Python del codice di Manlio.

-- 
 Daniele Tricoli 'Eriol'
 http://mornie.org
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Un videogioco fatto con la standard library

[Daniele Tricoli]

On Monday 12 December 2011 11:28:58 Francesco Maida wrote:
> Grazie, gli sto dando un'occhiata in questo momento, mi sembra molto
> più semplice da leggere rispetto all'altro codice sorgente.

Beh, io non mi ero posto il vincolo sul numero delle linee di codice :)

-- 
 Daniele Tricoli 'Eriol'
 http://mornie.org
___
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/13 Marco Mariani 

> 2011/12/13 enrico franchi 
>
> A me al momento non viene in mente proprio nessun metodo per farlo.
>>
>>
>>  Il problema principale e' che non ti fanno fare monkey patching degli
>> interi (o delle stringhe)...
>>
>>
> Questo e' un uso della parola "problema" che ancora non conoscevo.
>

LOL.



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

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

[Marco Mariani]

2011/12/13 Daniele Tricoli 

> Ovviamente usando:
> sys.excepthook = trick
>
> Ripeto, è soltanto un modo per far *apparire* lo stesso risultato: non è
il
> porting in Python del codice di Manlio.

Immagino che si possa fare qualcosa anche con un decoratore e il modulo
'ast' :-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] cgi ottimizzati ERA: web: sync vs. async

[Roberto De Ioris]

>
> Il "trucco" è usare un socket UNIX domain bidirezionale, invece di due
> pipe.
> In questo modo per Nginx la comunicazione con il processo CGI dovrebbe
> essere analoga a quella con un client remoto.
> In particolare non dovrebbe mai essere necessario chiamare waitpid.
>
>

Ma cosi' non mi ritrovo pieno di zombie ? Oppure intendi comunque chiamare
waitpid(-1...) a intervalli regolari per fare pulizia ? A rigor di logica
quando sei in attesa dello STDOUT del CGI se ricevi uno stream vuoto,
allora il processo dovrebbe aver finito il suo lavoro. Il problema e' se
qualche cgi "cattivo" chiama una close(1) nel suo codice. A quel punto la
chiamata a waitpid() sarebbe bloccante.

In realta' poi mi sono ricordato della nuova syscall signalfd (in linux)
che si potrebbe agganciare al SIGCHLD, quindi si potrebbe simulare il
comportamento di kqueue(). Probabilmente e' una strada percorribile, se
non fosse per il fatto che Igor e' da sempre allergico a chiamare fork()
(o clone()) in nginx, e quindi ho paura che una inclusione nel ramo
ufficiale potrebbe essere "problematica".

-- 
Roberto De Ioris
http://unbit.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python