[Python] Connessioni asincrone verso i database

[Alessandro Agosto]

>
> Node e` un server asincrono, lato cliente ci metti un qualsiasi client
> che parla quel protocollo. Se giri in HTTP un browser e un po' di
> JavaScript vanno benissimo :D Il client della chat demo che c'e` sul
> sito e` scritto in JavaScript con l'ausilio di jQuery:
> http://github.com/ry/node_chat/blob/master/client.js
>
Capito. Da una prima occhiata al sito pensavo fosse qualche nuova diavoleria
per interagire con un webserver asincrono :). Grazie per la spiegazione.

> Ciao!
>
Ciao e buona serata!

Il giorno 22 gennaio 2010 14.09, Manlio Perillo
<manlio.perillo a gmail.com>ha scritto:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Al momento non ricordo, cerca nella mailing list di psycopg.

Fatto. Ho trovato vari messaggi sul core asincrono e ho iniziato a scovare
qualche report di bug e vari, cercherò di raccogliere qualche info
specifica.

> >     > Altrimenti, se ho scritto una app in python che non è basata su
> >     twisted
> >     > ma volessi usare una delle sue interfacce asincrone per la
> connessione
> >     > ai db avrei qualche problema?
> >
> >     Probabilmente si.
> >
> > Allora l'unica soluzione credo sia testarle, magari con una semplice app
> > wsgi su un webserver asincrono.
> >
>
> Io per Twisted ho implementato un client in puro Python per PostgreSQL:
> http://hg.mperillo.ath.cx/twisted/pglib/
>
> Ma non l'ho mai usato in produzione.
>
Uhm. Adesso il webserver del link sopra mi restituisce un 504, appena torna
disponibile il servizio darò una occhiata con gran piacere :)

> Non dovrebbe.
> L'importante è che tu abbia un solo main loop per thread/processo.
>
Chiaro, beh questo allora potrebbe essere interessante. Si ovviamente il
main loop è uno solo attraverso cui passa tutto ciò che deve aspettare un
evento.

> No, è documentato da un altra parte:
> http://www.postgresql.org/docs/8.4/static/libpq-status.html
> `PQsocket`.
>
Ecco allora, la cosa si fà più chiara, ti ringrazio per la segnalazione,
darò una occhiata in questi giorni all'intera doc delle libpq, è veramente
interessante sotto quest'aspetto.

> Per applicazioni e database decenti, le query non ci mettono molto ad
> essere eseguite.
> Ed il database è comunque sullo stesso server o sulla stessa LAN.
>
Beh meno male che è cosi, comunque supponiamo di avere il webserver
asincrono e una applicazione ben progettata, è un vero peccato che il collo
di bottiglia possa diventare proprio quello che è (nella maggioranza dei
casi) il cuore dell'applicazione stessa -o forse è meglio dire il
"cervello"-

> Questo tipo di latenze si possono risolvere utilizzando un server che
> usi più di un processo per servire le richieste HTTP.
>
Questo è però più un metodo per tamponare il problema che per risolverlo.
Lasciamo un attimo da parte infatti i tempi brevi o non della connessione al
db, ma se io lancio 15 processi di un webserver e poi ho più richieste del
numero di processi in esecuzione semplicemente siam punto e a capo
(supponiamo un numero di gran lunga maggiore ai 15 processi).
In proposito sul web si trova qualche discussione -anche se breve- e
particolarmente mi viene in mente quella dello sviluppatore di un ws
asincrono e di uno sviluppatore web python, quando quest'ultimo ha appunto
detto che il numero consecutivo di processi non è una soluzione lo
sviluppatore del ws non ha più risposto :s

> Di nulla, ciao.
>
Ciao e buona serata :)

> _______________________________________________
> Python mailing list
> Python a lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
-- 
Alessandro A.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: http://lists.python.it/pipermail/python/attachments/20100122/67fa0d09/attachment.htm