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