Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-16 19:40 GMT+01:00 Roberto De Ioris robe...@unbit.it: [...] Le alternative che *io* vedo sono tutte architetturali, ovvero mettersi nell'ordine di idee di avere un pool di worker fuori dall'app web e delegare quasi ogni cosa li. Che sono le stesse che propongo io, django riceve la richiesta, fa tutti i controlli del caso (come l'autenticazione) e poi passa la connessione (o tramite proxy o tramite fd-passing su socket unix) al backend gevent che continua a gestire la sessione liberando django. Forse mi sono perso qualcosa, ma quale è la differenza tra questa soluzione ed avere Apache prefork con N + M processi? La soluzione che hai indicato è quella tipica frontend + backend, nel caso in cui il frontend sa gestire 10K ma il backend no (e spesso non deve farlo). Ma davvero ci sono vantaggi in un ulteriore livello, in cui l'applicazione Django minimale fa da frontend e tutto il resto (inclusa connessione al database) la fa un ulteriore backend? Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-16 19:40 GMT+01:00 Roberto De Ioris robe...@unbit.it: [...] Le alternative che *io* vedo sono tutte architetturali, ovvero mettersi nell'ordine di idee di avere un pool di worker fuori dall'app web e delegare quasi ogni cosa li. Che sono le stesse che propongo io, django riceve la richiesta, fa tutti i controlli del caso (come l'autenticazione) e poi passa la connessione (o tramite proxy o tramite fd-passing su socket unix) al backend gevent che continua a gestire la sessione liberando django. Forse mi sono perso qualcosa, ma quale è la differenza tra questa soluzione ed avere Apache prefork con N + M processi? La soluzione che hai indicato è quella tipica frontend + backend, nel caso in cui il frontend sa gestire 10K ma il backend no (e spesso non deve farlo). Ma davvero ci sono vantaggi in un ulteriore livello, in cui l'applicazione Django minimale fa da frontend e tutto il resto (inclusa connessione al database) la fa un ulteriore backend? Ti faccio l'esempio di un progetto sui cui ho lavorato di recente che deve fornire notifiche (tramite SSE) in tempo reale, scrivendo dei testi in un div. La parte SSE all'inizio deve essere comunque autenticata, deve prendere dei dati dal db per scegliere che tipo di informazioni mi servono, dopo di che django non serve piu', i dati che mi arrivano sono presi da redis. Quindi una volta che django ha autenticato l'utente, e scelto cosa fargli vedere, passa la connessione (la tecnica usata e' irrilevante) al livello back-backend (chiamiamolo cosi') che si occupa di leggere in maniera non bloccante da una coda redis e inviare le informazioni (e la cosa potrebbe durare ore). A questo punto django ha finito il suo ciclo di richiesta ed e' pronto a gestirne un' altra. Il giro e' proxy non bloccante - application server bloccante - application server non bloccante. Non parlerei di vantaggi, ma di necessita', far digerire a django il modello gevent (o quello che sia) e' talmente tedioso come processo che tanto vale aggiungere un ulteriore strato. E' un po' piu' macchinoso senza dubbio, ma non ha (teoricamente) sorprese sul medio e lungo termine. Io non metto in dubbio che avere tutto non bloccante da cima a fondo sia l'approccio migliore, ma una azienda che ha investito in Django non passa a tornado da un giorno all'altro (o a nodejs o a Go o a Rust ecc. ecc.), quindi bisogna ricorrere a workaround che comunque mantengano un certo di grado di solidita'. (e poi devo ancora trovarne di framework non-blocking-friendly che siano al livello di django) Poi se alcune aziende ci riescono, buon per loro, hanno il mio rispetto e la mia somma invidia :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-15 7:42 GMT+01:00 Nicola Larosa n...@teknico.net: Manlio Perillo wrote: [...] Twisted offre un framework per la programmazione asincrona da anni, ma non è mai stato di moda, perchè molto più difficile. Non ha avuto grande successo per vari altri motivi: avanti sui suoi tempi, documentazione carente, e anche insistenza sulla sintassi a callback preferita alle inline callback. Secondo me molto ha influito il fatto che non fosse compatibile con il resto del mondo Python. Considerato tutti i problemi che gli utenti hanno con tornado e friends (e che nemmeno sanno di sapere), direi che, come sempre, explicit is better than implicit. Poco ma sicuro. Creare punti impliciti di cambio di contesto, come fanno gevent ed eventlet, e come fanno i thread preemptive, è ingestibile. Si, ma con gevent i punti di cambio di contesto sono deterministici. Non sono espliciti, ma se la libreria che usa le coroutine è scritta bene sai dove può avvenire lo switch, anche se magari sommerso tra 5-10 funzioni (cosa non bella, in effetti, ma è proprio uno dei problemi con yield che ti devi portare dietro sempre) Il mio suggerimento è sempre quello di imparare prima le basi (vicino a quello che realmente succede) e solo dopo utilizzare cose che rendono la programmazione e manutenzione più semplice. Se con questo intendi passare per la sintassi a callback prima di usare la pseudo sincrona, non sono d'accordo. No, indendevo capire quello che succede sotto il cofano, altrimento non ci si rende conto dei possibili problemi e/o come risolverli. Non si tratta di basi, è semplicemente un modo diverso, molto meno leggibile, di scrivere codice asincrono. Ormai le Promises ci sono anche in Javascript, non ha senso insistere col vecchio modello. Però andare troppo oltre e rinunciare agli yield, che marcano i punti di cambio di contesto, significa andarsela a cercare. Glyph Lefkowitz, cioè Mr. Twisted, fa un'ottima panoramica delle opzioni disponibili, ed illustra bene i pericoli di usare una sintassi implicita: 1. Straight callbacks: Twisted’s IProtocol, JavaScript’s onfoo idiom, where you give a callback to something which will call it later and then return control to something (usually a main loop) which will execute those callbacks, 2. “Managed” callbacks, or Futures: Twisted’s Deferred, JavaScript’s Promises/A[+], E’s Promises, where you create a dedicated result-that-will-be-available-in-the-future object and return it for the caller to add callbacks to, 3. Explicit coroutines: Twisted’s @inlineCallbacks, Tulip’s yield from coroutines, C#’s async/await, where you have a syntactic feature that explicitly suspends the current routine, 4. and finally, implicit coroutines: Java’s “green threads”, Twisted’s Corotwine, eventlet, gevent, where any function may switch the entire stack of the current thread of control by calling a function which suspends it. Go non ha una sintassi per sospendere esplicitamente una goroutine; quindi appartiene a 4) ? [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Nicola Larosa wrote: 3. Explicit coroutines: Twisted’s @inlineCallbacks, Tulip’s yield from coroutines, C#’s async/await, where you have a syntactic feature that explicitly suspends the current routine, 4. and finally, implicit coroutines: Java’s “green threads”, Twisted’s Corotwine, eventlet, gevent, where any function may switch the entire stack of the current thread of control by calling a function which suspends it. Manlio Perillo wrote: Go non ha una sintassi per sospendere esplicitamente una goroutine; quindi appartiene a 4)? La sospensione avviene quando una goroutine manda un valore su un canale non bufferizzato: fin quando un'altra goroutine non legge quel valore, la prima è bloccata. E poi ovviamente anche quando una goroutine riceve un valore da un canale non bufferizzato, o vuoto. Invio e ricezione fanno parte della sintassi del linguaggio, tramite gli operatori freccia - e -. -- Nicola Larosa - http://www.tekNico.net/ A plus sign is just a square with collapsed sides, after passing through a hash sign: ◽ # + (Where are my medications when I need them?) - Nicola Larosa, February 2014 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
On Mon, Mar 17, 2014 at 12:34 PM, Nicola Larosa n...@teknico.net wrote: Nicola Larosa wrote: 3. Explicit coroutines: Twisted’s @inlineCallbacks, Tulip’s yield from coroutines, C#’s async/await, where you have a syntactic feature that explicitly suspends the current routine, 4. and finally, implicit coroutines: Java’s “green threads”, Twisted’s Corotwine, eventlet, gevent, where any function may switch the entire stack of the current thread of control by calling a function which suspends it. Manlio Perillo wrote: Go non ha una sintassi per sospendere esplicitamente una goroutine; quindi appartiene a 4)? La sospensione avviene quando una goroutine manda un valore su un canale non bufferizzato: fin quando un'altra goroutine non legge quel valore, la prima è bloccata. E poi ovviamente anche quando una goroutine riceve un valore da un canale non bufferizzato, o vuoto. Invio e ricezione fanno parte della sintassi del linguaggio, tramite gli operatori freccia - e -. Si, ma una scrittuta/lettura su un canale possono essere nidificate all'interno di N funzioni. Non è' lo stesso di quello che accade con gevent? Con yield è diverso, perchè deve essere presente in ogni livello di chiamata a funzione. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-17 11:22 GMT+01:00 Roberto De Ioris robe...@unbit.it: [...] Forse mi sono perso qualcosa, ma quale è la differenza tra questa soluzione ed avere Apache prefork con N + M processi? La soluzione che hai indicato è quella tipica frontend + backend, nel caso in cui il frontend sa gestire 10K ma il backend no (e spesso non deve farlo). Ma davvero ci sono vantaggi in un ulteriore livello, in cui l'applicazione Django minimale fa da frontend e tutto il resto (inclusa connessione al database) la fa un ulteriore backend? Ti faccio l'esempio di un progetto sui cui ho lavorato di recente che deve fornire notifiche (tramite SSE) in tempo reale, scrivendo dei testi in un div. La parte SSE all'inizio deve essere comunque autenticata, deve prendere dei dati dal db per scegliere che tipo di informazioni mi servono, dopo di che django non serve piu', i dati che mi arrivano sono presi da redis. Quindi una volta che django ha autenticato l'utente, e scelto cosa fargli vedere, passa la connessione (la tecnica usata e' irrilevante) Irrilevante, ma altamente dipendente dal sistema operativo e non tutti la supportano :) al livello back-backend (chiamiamolo cosi') che si occupa di leggere in maniera non bloccante da una coda redis e inviare le informazioni (e la cosa potrebbe durare ore). A questo punto django ha finito il suo ciclo di richiesta ed e' pronto a gestirne un' altra. In effetti questo è un caso particolare che non avevo considerato. Il giro e' proxy non bloccante - application server bloccante - application server non bloccante. Non parlerei di vantaggi, ma di necessita', far digerire a django il modello gevent (o quello che sia) e' talmente tedioso come processo che tanto vale aggiungere un ulteriore strato. E' un po' piu' macchinoso senza dubbio, ma non ha (teoricamente) sorprese sul medio e lungo termine. Questo non è un caso d'uso dei web sockets? Il problema è l'autenticazione; con la soluzione attuale il back-back-end riceve dati da una fonte sicura. Però con i websockets potresti disaccoppiare completamente i due backend (?). Io non metto in dubbio che avere tutto non bloccante da cima a fondo sia l'approccio migliore, ma una azienda che ha investito in Django non passa a tornado da un giorno all'altro (o a nodejs o a Go o a Rust ecc. ecc.), quindi bisogna ricorrere a workaround che comunque mantengano un certo di grado di solidita'. (e poi devo ancora trovarne di framework non-blocking-friendly che siano al livello di django) Vero, ma bisogna stare attenti a non cadere nella sindrome dell'utilizzo a tutti costi perchè è l'unica cosa che conosco/conoscono gli altri. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-16 4:46 GMT+00:00 Roberto De Ioris robe...@unbit.it: Mi rendo conto che non e' un approccio molto tecnico, ma francamente sentirmi dire che cazzo dici !!! ho letto sul blog di topogigio che si puo' fare e senza sforzo, beh un pochino mi rode... Scusa, ma esattamente la soluzione quale sarebbe? Perche' niente da dire sul fare chiarezza riguardo i problemi di gevent e simili, ma io non e' che vedo molte soluzioni. Perche' programmare multithreading preemptivo ha pure tutti i suoi problemi, multiprocesso puro scala solo fino ad un certo punto e lavorare interamente a callback ha pure gli stessi problemi di gevent dal punto di vista di quello che *non* puoi fare (se non che quelli di twisted sono stati piu' chiari nel dire chiaro e tondo quello che *non* potevi fare gratis) e mi pare di ricordare che lo trovi molto meno comodo -- e se non fosse che mi sono girato la testa per trovare naturale CPS e sono fatto strano io -- sono in essenza d'accordo. Le alternative che *io* vedo sono tutte architetturali, ovvero mettersi nell'ordine di idee di avere un pool di worker fuori dall'app web e delegare quasi ogni cosa li. D'altra parte i problemi di dare in mano qualcosa di asincrono a chi non ha idea sono ben esemplificati da quello che succede a molta gente che cerca di fare roba con node.js. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-16 4:46 GMT+00:00 Roberto De Ioris robe...@unbit.it: Mi rendo conto che non e' un approccio molto tecnico, ma francamente sentirmi dire che cazzo dici !!! ho letto sul blog di topogigio che si puo' fare e senza sforzo, beh un pochino mi rode... Scusa, ma esattamente la soluzione quale sarebbe? Perche' niente da dire sul fare chiarezza riguardo i problemi di gevent e simili, ma io non e' che vedo molte soluzioni. Perche' programmare multithreading preemptivo ha pure tutti i suoi problemi, multiprocesso puro scala solo fino ad un certo punto e lavorare interamente a callback ha pure gli stessi problemi di gevent dal punto di vista di quello che *non* puoi fare (se non che quelli di twisted sono stati piu' chiari nel dire chiaro e tondo quello che *non* potevi fare gratis) e mi pare di ricordare che lo trovi molto meno comodo -- e se non fosse che mi sono girato la testa per trovare naturale CPS e sono fatto strano io -- sono in essenza d'accordo. Le alternative che *io* vedo sono tutte architetturali, ovvero mettersi nell'ordine di idee di avere un pool di worker fuori dall'app web e delegare quasi ogni cosa li. Che sono le stesse che propongo io, django riceve la richiesta, fa tutti i controlli del caso (come l'autenticazione) e poi passa la connessione (o tramite proxy o tramite fd-passing su socket unix) al backend gevent che continua a gestire la sessione liberando django. Il client non si accorge di nulla. Se ci sono altri modi piu' semplici, io personalmente non li ho trovati. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-16 18:40 GMT+00:00 Roberto De Ioris robe...@unbit.it: Che sono le stesse che propongo io, django riceve la richiesta, fa tutti i controlli del caso (come l'autenticazione) e poi passa la connessione (o tramite proxy o tramite fd-passing su socket unix) al backend gevent che continua a gestire la sessione liberando django. Il client non si accorge di nulla. Se ci sono altri modi piu' semplici, io personalmente non li ho trovati. Ah no, sono d'accordo. In generale non c'e' molto che puoi fare. Ad un certo punto abbiamo tirato su un accrocchio con multiprocess e django[0] che grida vendetta ma funziona decisamente meglio delle alternative. Parlami dell'fd-passing, mi interessa. So come farlo in C, ma non ho mai provato in Python direttamente. E poi che passi, direttamente il socket della request e quindi fai anche lo string munching per costruire le pagine nel backend? -- [0] django per inciso si era spaccato malissimo ai timidi tentativi di multi-patching di gevent, viceversa, tirare su processi con multiprocess e patchare quelli funziona benino. Certo... appena ho tempo celery o simile e tanti calci di meno. Pero' per qualcosa che e' stato messo su a calci in un pomeriggio ha funzionato bene. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Manlio Perillo wrote: Come vedi diventa molto complicato, specialmente se ad esempio devi fare il parsing di un protocollo come HTTP (puoi vedere il codice di Twisted se ti interessa). Twisted non si limita alle callback lisce ma ne gestisce esplicitamente i flusso (con i Deferred), e supporta anche la sintassi pseudo sincrona, stile coroutine, tramite le inline callbacks (opzioni 1, 2 e 3 sotto). Lo stesso fa Tornado. Tra l'altro il motivo perchè tornado va di moda è perchè permette di avere il codice che è praticamente lo stesso di quello normale, ma che si comporta in modo completamente diverso. Cioè la sintassi pseudo sincrona. Tornado supporta anche la sintassi a callback gestita (tramite i Future). Twisted offre un framework per la programmazione asincrona da anni, ma non è mai stato di moda, perchè molto più difficile. Non ha avuto grande successo per vari altri motivi: avanti sui suoi tempi, documentazione carente, e anche insistenza sulla sintassi a callback preferita alle inline callback. Considerato tutti i problemi che gli utenti hanno con tornado e friends (e che nemmeno sanno di sapere), direi che, come sempre, explicit is better than implicit. Poco ma sicuro. Creare punti impliciti di cambio di contesto, come fanno gevent ed eventlet, e come fanno i thread preemptive, è ingestibile. Un linguaggio recente come Go usa solo la sintassi pseudo sincrona, tramite goroutine e channel. Però lo scheduler è preemptive e il runtime fa un mapping N-to-M delle goroutine ai thread di sistema, permettendo di usare in modo trasparente tutti i core di CPU disponibili. Quest'approccio consente di mischiare in modo trasparente codice sincrono e asincrono. Devo invocare un adapter db sincrono, cioè bloccante? Non devo preoccuparmi di incapsulare manualmente la chiamata in un thread o processo separato: il runtime si accorgerà che il thread assegnato è bloccato, e sposterà automaticamente le altre goroutine assegnate a quel thread su altri thread. Essendo comunque un sistema preemptive a stato condiviso, rimane al programmatore la responsabilità di non reintrodurre i problemi del multithreading classico. Il linguaggio incoraggia l'approccio robusto, ma non lo rende obbligato. Approfondimenti: The Go scheduler http://morsmachine.dk/go-scheduler Why is this Go code blocking? http://stackoverflow.com/questions/12413510/why-is-this-go-code-blocking Il mio suggerimento è sempre quello di imparare prima le basi (vicino a quello che realmente succede) e solo dopo utilizzare cose che rendono la programmazione e manutenzione più semplice. Se con questo intendi passare per la sintassi a callback prima di usare la pseudo sincrona, non sono d'accordo. Non si tratta di basi, è semplicemente un modo diverso, molto meno leggibile, di scrivere codice asincrono. Ormai le Promises ci sono anche in Javascript, non ha senso insistere col vecchio modello. Però andare troppo oltre e rinunciare agli yield, che marcano i punti di cambio di contesto, significa andarsela a cercare. Glyph Lefkowitz, cioè Mr. Twisted, fa un'ottima panoramica delle opzioni disponibili, ed illustra bene i pericoli di usare una sintassi implicita: 1. Straight callbacks: Twisted’s IProtocol, JavaScript’s onfoo idiom, where you give a callback to something which will call it later and then return control to something (usually a main loop) which will execute those callbacks, 2. “Managed” callbacks, or Futures: Twisted’s Deferred, JavaScript’s Promises/A[+], E’s Promises, where you create a dedicated result-that-will-be-available-in-the-future object and return it for the caller to add callbacks to, 3. Explicit coroutines: Twisted’s @inlineCallbacks, Tulip’s yield from coroutines, C#’s async/await, where you have a syntactic feature that explicitly suspends the current routine, 4. and finally, implicit coroutines: Java’s “green threads”, Twisted’s Corotwine, eventlet, gevent, where any function may switch the entire stack of the current thread of control by calling a function which suspends it. One of these things is not like the others; one of these things just doesn’t belong. Unyielding - Deciphering Glyph https://glyph.twistedmatrix.com/2014/02/unyielding.html L'opzione fuori posto è ovviamente la quarta. -- Nicola Larosa - http://www.tekNico.net/ A plus sign is just a square with collapsed sides, after passing through a hash sign: ◽ # + (Where are my medications when I need them?) - Nicola Larosa, February 2014 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
On 2014-03-15 05:54, Nicola Larosa wrote: Daniele Varrazzo wrote: Purtroppo tulip non si integra bene con il supporto green di psycopg, perché è basato su yield Chissà come mai Guido ci tiene tanto a questa seccatura dello yield... con tutti gli yeldini al posto loro. E non solo lui, a quanto pare. Ecco ben spiegata la prospettiva di noi comuni mortali che bizzarramente ci teniamo così tanto ad avere tutti gli yeldini al posto loro. Quello di essere espliciti è senz'altro un modello superiore. Il modo green è solo un truccazzo per avere interfacce bloccanti in un ambiente asincrono, il che ci ha permesso di arrivare al 2014. Ovvero: vuoi usare django in maniera asincrona? Prova a farlo con yield... Vuoi usare SQLAlchemy? Uhmm, ritenta, sarai più fortunato. Ho conosciuto comuni mortali che avevano bisogno di queste cose (twisted tendevano a usarlo i semidei e altri impiegati olimpici). Il futuro è quello? Non c'è problema per me. Ma `questo http://python.org/dev/peps/pep-0249/`__ va riscritto, come tutti i programmi che ci sono progettati ed implementati sopra, e non so se tu ci avevi pensato. La mia non era una nota polemica come hai letto tu: le interfacce sono state rotte: vanno riprogettate e i programmi dovranno essere riscritti; questo è un dato di fatto. Unyielding - Deciphering Glyph https://glyph.twistedmatrix.com/2014/02/unyielding.html Che è poi il motivo per cui ho usato Twisted per anni, apprezzo Tornado (e Go), e non mi vedrete tanto presto a usare gevent, eventlet e compagnia, per non dire mai. È fico essere duri e puri. Io invece mi sono trovato nella posizione di scrivere software che altri devono usare: a volte nella maniera in cui lo userei anche io, a volte no. Sono sicuro che il supporto a librerie di coroutine abbia aiutato più di qualche persona, e questo mi fa piacere nonostante ci siano sempre gli odiatori di professione (gironzolare su twitter per cercare feedback sul proprio lavoro è come andare sulle montagne russe). -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-14 23:33 GMT+01:00 Balan Victor balan.vict...@gmail.com: Il giorno 14 marzo 2014 18:12, Manlio Perillo manlio.peri...@gmail.comha scritto: 2014-03-13 19:35 GMT+01:00 Balan Victor balan.vict...@gmail.com: Di recente ho letto un po di tornado, e in particolare mi sono soffermato sul modulo tornado.httpserver(Non-blocking HTTP server). Stando a quello che c'è scritto sulla documentazione ufficiale parla di non-blocking, single-threaded HTTP server e di risolvere il problemi di tipo C10K. Qua sembra interessante, anche se non ho la minima idea di come funzioni. [...] L'argomento è complesso. hai da consigliare qualche post/documento/libero che spiega bene l'argomento?(Italiano/Inglese) ? Su google ne ho trovato alcuni ma non sono il massimo della chiarezza Purtroppo no. Nel caso di un server C10K ready ci sono due aspetti principali. Il primo riguarda tutto quel codice che esegue una richiesta ed aspetta una risposta. Il secondo riguarda il paradigma utilizzato per gestire il flusso del codice. Il 97.7% delle librerie disponibili fa qualcosa del tipo: status = send_request(data) resp = recv_response() Entrambe le funzioni potrebbero metterci molto tempo a completare, ma questo codice blocca l'intero thread fino a quando resp non è disponibile. Quello che fa tornado è di usare quelle che si chiamano coroutine, o threading cooperativo. In questo caso sia send_request che recv_response bloccano il flusso corrente del codice (la coroutine corrente), ma non l'intero thread perchè usando le coroutine viene effettuato un salto (simile al goto) che va ad eseguire altre funzioni coroutine. e se dentro recv_response ho una chiamata al db perché mi dovrebbe bloccare? Se usi la libreria giusta non blocca. Ad esempio la libpq ha un API scritta come si deve (una delle poche, purtroppo, almeno per quello che so) e che permette di fare richieste asincrone. se sono eseguiti in coruotine la chiamata al db non dovrebbe andare a girare in qualche modo in background? Come detto, devi usare la libreria giusta. PostgreSQL usa libpq che offre un API asincrona, e psycopg usa questa API e le coroutine per fornire una API semplice. Vedi la documentazione sa: gevent (l'implementazione delle coroutine) sembra risolva tutti i problemi, ma in realtà tutto quello che fa ha un costo. Non è un caso che i web server C10K usano la programmazione tramite callback e macchina a stati; questo perchè è molto più efficiente nella gestione della memoria. Ogni coroutine è come un thread ed ha bisogno di memoria per lo stack, oltre poi al costo per il context switch. E i multiprocessing? Quello che fanno le implementazioni delle coroutine più avanzate, come GHC, Erlang e Go è di reimplementare in user space quello che fa il kernel con i processi, in modo più semplice (perchè il contesto associato ad un green thread è più piccolo rispetto a quello associato ad un processo) ed efficiente, oltre che più prevedibile. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-15 0:54 GMT+01:00 Giampaolo Rodola' g.rod...@gmail.com: 2014-03-14 18:12 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: Ogni coroutine è come un thread ed ha bisogno di memoria per lo stack, oltre poi al costo per il context switch. Rispetto ad un thread il costo è però pressochè nullo. Roberto tempo fa ha scritto che ha visto applicazioni con gevent con utilizzo pesante della CPU, nel caso di molte coroutine. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-15 0:54 GMT+01:00 Giampaolo Rodola' g.rod...@gmail.com: 2014-03-14 18:12 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: Ogni coroutine è come un thread ed ha bisogno di memoria per lo stack, oltre poi al costo per il context switch. Rispetto ad un thread il costo è però pressochè nullo. Roberto tempo fa ha scritto che ha visto applicazioni con gevent con utilizzo pesante della CPU, nel caso di molte coroutine. purtroppo si, le greenlet hanno comunque uno stack e gevent comunque in media chiama molte piu' syscall rispetto ad un uso classico (per svariati motivi). E' un prodotto/progetto che adoro, ma va' usato nei posti e nel modo giusto. Oggi ho buttato giu' questo: http://uwsgi-docs.readthedocs.org/en/latest/articles/OffloadingWebsocketsAndSSE.html ... bisogna farla finita di credere alla favola che django gira gratis su gevent (tantomeno su tornado)... Non c'e' niente da fare, il vantaggio di nodejs, Go ecc. ecc. e' che TUTTE le librerie di terze parti sono non-blocking-friendly (passatemi il termine) e quindi gli utenti (piu' o meno) non devono preoccuparsi di nulla... questo non puo' avvenire (facilmente) con i linguaggi che sono nati in un mondo multiprocess/multithread e che gia' hanno una libreria sconfinata di moduli di terze parti (costruita in decenni).. In ogni caso il passaggio non potra' essere indolore (e gia' ci sono le prime vittime, senza contare quelli che hanno proprio disertato cambiando bandiera...) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Roberto De Ioris wrote: Non c'e' niente da fare, il vantaggio di nodejs, Go ecc. ecc. e' che TUTTE le librerie di terze parti sono non-blocking-friendly (passatemi il termine) e quindi gli utenti (piu' o meno) non devono preoccuparsi di nulla... No, questo per Go non è vero. Vedi la mia risposta a Manlio di stamattina. -- Nicola Larosa - http://www.tekNico.net/ A plus sign is just a square with collapsed sides, after passing through a hash sign: ◽ # + (Where are my medications when I need them?) - Nicola Larosa, February 2014 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Roberto De Ioris wrote: Non c'e' niente da fare, il vantaggio di nodejs, Go ecc. ecc. e' che TUTTE le librerie di terze parti sono non-blocking-friendly (passatemi il termine) e quindi gli utenti (piu' o meno) non devono preoccuparsi di nulla... No, questo per Go non è vero. Vedi la mia risposta a Manlio di stamattina. In che senso ? nella peggiore delle ipotesi Go fa' l'offloading su un pthread, quindi comunque l'utente e' salvo. O intendi altro ? -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Roberto De Ioris wrote: Non c'e' niente da fare, il vantaggio di nodejs, Go ecc. ecc. e' che TUTTE le librerie di terze parti sono non-blocking-friendly (passatemi il termine) e quindi gli utenti (piu' o meno) non devono preoccuparsi di nulla... Nicola Larosa wrote: No, questo per Go non è vero. Vedi la mia risposta a Manlio di stamattina. In che senso? nella peggiore delle ipotesi Go fa l'offloading su un pthread, quindi comunque l'utente e' salvo. O intendi altro ? È vero che l'utente non deve preoccuparsi di nulla, ma non perché le librerie siano tutte non bloccanti bensì perché, come dicevo, Go consente di mischiare in modo trasparente codice sincrono e asincrono. Credo che offloading su pthread corrisponda a quello che descrivevo come mapping N-to-M delle goroutine ai thread di sistema. Giusto? -- Nicola Larosa - http://www.tekNico.net/ A plus sign is just a square with collapsed sides, after passing through a hash sign: ◽ # + (Where are my medications when I need them?) - Nicola Larosa, February 2014 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Roberto De Ioris wrote: Non c'e' niente da fare, il vantaggio di nodejs, Go ecc. ecc. e' che TUTTE le librerie di terze parti sono non-blocking-friendly (passatemi il termine) e quindi gli utenti (piu' o meno) non devono preoccuparsi di nulla... Nicola Larosa wrote: No, questo per Go non è vero. Vedi la mia risposta a Manlio di stamattina. In che senso? nella peggiore delle ipotesi Go fa l'offloading su un pthread, quindi comunque l'utente e' salvo. O intendi altro ? È vero che l'utente non deve preoccuparsi di nulla, ma non perché le librerie siano tutte non bloccanti bensì perché, come dicevo, Go consente di mischiare in modo trasparente codice sincrono e asincrono. ah ok giustissimo, ma calcola anche che praticamente tutta la standard library di Go e' non-bloccante, il che lo mette in posizione di vantaggio (e anche di tanto) rispetto a python (o a perl o a ruby) anche se gli ultimi progetti che ho rilasciato sono in go, ancora non mi sono innamorato, ma sarei ingiusto a dire che non e' fantastico nella maggior parte delle cose che fa... Credo che offloading su pthread corrisponda a quello che descrivevo come mapping N-to-M delle goroutine ai thread di sistema. Giusto? si esatto, anche la nomenclatura che usano e' piu' fica di quella degli altri :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
On 2014-03-15 18:08, Roberto De Ioris wrote: Oggi ho buttato giu' questo: http://uwsgi-docs.readthedocs.org/en/latest/articles/OffloadingWebsocketsAndSSE.html Grazie, me lo rileggo domani con un tasso di sangue nell'alcol più alto. Ma, domanda veloce: This is the whole point of this article: do not use the Django ORM in your gevent apps unless you know what you are doing !!! (read, you have a django database adapter that supports gevent and does not sucks compared to the standard ones...) Con questo dici: 1. impossibile usare django+gevent+psycopg2 in maniera realmente non blocking 2. gevent+psycopg2 funzionerebbe se avesse un wrapper django diverso/migliore 3. django+gevent+psycopg2 funzionano, altri driver/database no 4. vai a letto piro, non c'hai capito niente ed è tardi Grazie ancora :) -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
On 2014-03-15 18:08, Roberto De Ioris wrote: Oggi ho buttato giu' questo: http://uwsgi-docs.readthedocs.org/en/latest/articles/OffloadingWebsocketsAndSSE.html Grazie, me lo rileggo domani con un tasso di sangue nell'alcol più alto. Ma, domanda veloce: This is the whole point of this article: do not use the Django ORM in your gevent apps unless you know what you are doing !!! (read, you have a django database adapter that supports gevent and does not sucks compared to the standard ones...) Con questo dici: 1. impossibile usare django+gevent+psycopg2 in maniera realmente non blocking 2. gevent+psycopg2 funzionerebbe se avesse un wrapper django diverso/migliore 3. django+gevent+psycopg2 funzionano, altri driver/database no 4. vai a letto piro, non c'hai capito niente ed è tardi Grazie ancora :) Nessuna di queste :) ci sono adapter che hanno funzionato (notare il passato), altri che funzionano il 90% delle volte e cosi' via. Il mio obiettivo e' insinuare il dubbio, perche' se usi queste tecnologie devi porti delle domande, e non solo sui db, su ogni punto della tua applicazione. Mi rendo conto che non e' un approccio molto tecnico, ma francamente sentirmi dire che cazzo dici !!! ho letto sul blog di topogigio che si puo' fare e senza sforzo, beh un pochino mi rode... Ad esempio la funzione di entropia di openssl e' ultra-bloccante, e guarda un po' l'ho vista usata in un app django-gevent... (comunque, questo, basato su psycogreen, funziona molto bene: https://github.com/jneight/django-db-geventpool) Dei tutorial (quelli diciamo piu' famosi), che ci sono su django + gevent, solo uno riporta psycogreen, gli altri glissano o consigliano di usare adapter pure-python (che sono spesso lontani dall'essere full-featured) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Di recente ho letto un po di tornado, e in particolare mi sono soffermato sul modulo tornado.httpserver(Non-blocking HTTP server). Stando a quello che c'è scritto sulla documentazione ufficiale parla di non-blocking, single-threaded HTTP server e di risolvere il problemi di tipo C10K. Qua sembra interessante, anche se non ho la minima idea di come funzioni. Sono rimasto perplesso quando ho provato a cercare qualche ORM da usare con tornado e non ho trovato nulla. Dopo un po di ricerche, da quello che ho capito, un orm non è fatto per lavorare in maniera asincrona. E non ho neppure trovato una libreria per collegarsi a qualche tipo di database relazione(a parte quella con MySql ma sembra non più supportata). Detto questo, non riesco a capire l'utilità di un HTTP Server con performance elevatissime ma che non permetta una minima interazione con il database. Probabilmente sopra ho scritto delle cavolate ma mi mancano completamente le basi per questo tipo di argomenti e volevo capire meglio come funzionano e quali sono i campi di applicazione di tecnologie simili. Non hai scritto cavolate, e anzi ti faccio i complimenti perche' nonostante dichiari di non capire bene la materia in realta' ti sei accorto del (secondo me) problema piu' grosso di tutte le tecnologie non-blocking nel mondo python: sono vendute MALISSIMO, in modo quasi dannoso. Il paradigma non-blocking ha una semplice regola: o sei non-blocking al 100% oppure la tua app non funziona. punto. il 99.999% non e' sufficiente. Una singola parte non bloccante ti manda l'app in malora. (ovvio, si potrebbero non avere problemi per mesi, ma all'improvviso una query resta bloccata e tutta l'app va giu'...) Ad oggi ho fatto consulenza su quasi 200 app Django che giravano su uWSGI+gevent o gunicorn+gevent. Di queste neanche il 10% erano corrette in quanto la maggior parte usavano i db adapter standard, o si collegavano a servizi esterni (come api http) usando moduli blocking e cosi' via. Parliamo di quasi il 90% di utenti che stanno usando una tecnologia in modo sbagliato e che continuano a pubblicizzare il loro successo con gevent. La stessa cosa succede con tornado, eventlet e sono sicuro che succedera' con asyncio/tulip Uno dei punti di forza di python (secondo me) e' la gigantesca disponibilita' di moduli, e un utente medio si aspetta di poter continuare a usarli tutti senza problemi, soprattutto se NON gli comunichi a caratteri cubitali tutte le implicazioni del non-blocking (e invece gli porti solo i vantaggi) Detto questo, ci sono comunque diversi moduli async-friendly/tornado-friendly ma sono spesso progettini, a volte sviluppati senza l'attenzione necessaria ad un modulo db-adapter (vedere il lavoro titanico che c'e' dietro a psycopg2, che per la cronaca puo' essere adattato al non-blocking) In conclusione, se sei fortunato troverai un adapter per il tuo db che funziona con tornado, ma dovrai tenere a mente che ogni volta che introduci una funzionalita' questa dovra' cooperare con il resto del sistema. -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Uno dei punti di forza di python (secondo me) e' la gigantesca disponibilita' di moduli, e un utente medio si aspetta di poter continuare a usarli tutti senza problemi, soprattutto se NON gli comunichi a caratteri cubitali tutte le implicazioni del non-blocking (e invece gli porti solo i vantaggi ecco, io rientro nella categoria utente medio XD un po per colpa mia un po perché non ho mai avuto la necessità del NON-BLOCKING e non mi ero interessato della cosa. Detto questo, ci sono comunque diversi moduli async-friendly/tornado-friendly ma sono spesso progettini, a volte sviluppati senza l'attenzione necessaria ad un modulo db-adapter (vedere il lavoro titanico che c'e' dietro a psycopg2, che per la cronaca puo' essere adattato al non-blocking per psycopg2 ho visto che esiste momoko(come sugerito da Dario) però mi sono accorto che in realtà non ti risolve del tutto il problema perché alla fine sei vincolato alla dimensione del connection pool. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-14 8:26 GMT+01:00 Roberto De Ioris robe...@unbit.it: Detto questo, ci sono comunque diversi moduli async-friendly/tornado-friendly ma sono spesso progettini, a volte sviluppati senza l'attenzione necessaria ad un modulo db-adapter (vedere il lavoro titanico che c'e' dietro a psycopg2, che per la cronaca puo' essere adattato al non-blocking) Mi interessa. In che modo? -- Giampaolo - http://grodola.blogspot.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Il giorno 14 marzo 2014 13:17, Giampaolo Rodola' g.rod...@gmail.com ha scritto: 2014-03-14 8:26 GMT+01:00 Roberto De Ioris robe...@unbit.it: Detto questo, ci sono comunque diversi moduli async-friendly/tornado-friendly ma sono spesso progettini, a volte sviluppati senza l'attenzione necessaria ad un modulo db-adapter (vedere il lavoro titanico che c'e' dietro a psycopg2, che per la cronaca puo' essere adattato al non-blocking) Mi interessa. In che modo? penso si riferisse a https://github.com/FSX/momoko ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Il 14 marzo 2014 13:35, Balan Victor balan.vict...@gmail.com ha scritto: Il giorno 14 marzo 2014 13:17, Giampaolo Rodola' g.rod...@gmail.com ha scritto: 2014-03-14 8:26 GMT+01:00 Roberto De Ioris robe...@unbit.it: Detto questo, ci sono comunque diversi moduli async-friendly/tornado-friendly ma sono spesso progettini, a volte sviluppati senza l'attenzione necessaria ad un modulo db-adapter (vedere il lavoro titanico che c'e' dietro a psycopg2, che per la cronaca puo' essere adattato al non-blocking) Mi interessa. In che modo? penso si riferisse a https://github.com/FSX/momoko Io invece credo parlasse di http://initd.org/psycopg/docs/advanced.html#support-for-coroutine-libraries © -- :**THE BEER-WARE LICENSE** (Revision 42): ``miron AT python.it`` wrote this mail. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return. --*Carlo Miron* .. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
On 14 Mar 2014, at 14:03, Carlo Miron mi...@python.it wrote: Io invece credo parlasse di http://initd.org/psycopg/docs/advanced.html#support-for-coroutine-libraries +1 Da cui, poi, si arriva a **psycogreen** : https://bitbucket.org/dvarrazzo/psycogreen/ -- valerio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
On 2014-03-14 13:58, Roberto De Ioris wrote: Il 14 marzo 2014 13:35, Balan Victor balan.vict...@gmail.com ha scritto: Il giorno 14 marzo 2014 13:17, Giampaolo Rodola' g.rod...@gmail.com ha scritto: 2014-03-14 8:26 GMT+01:00 Roberto De Ioris robe...@unbit.it: Detto questo, ci sono comunque diversi moduli async-friendly/tornado-friendly ma sono spesso progettini, a volte sviluppati senza l'attenzione necessaria ad un modulo db-adapter (vedere il lavoro titanico che c'e' dietro a psycopg2, che per la cronaca puo' essere adattato al non-blocking) Mi interessa. In che modo? penso si riferisse a https://github.com/FSX/momoko Io invece credo parlasse di http://initd.org/psycopg/docs/advanced.html#support-for-coroutine-libraries esatto, proprio questo Tra l'altro un mio collega mi ha portato all'attenzione un progetto di integrazione tra psycopg e tulip che però non è un gran che. Purtroppo tulip non si integra bene con il supporto green di psycopg, perché è basato su yield, quindi invece di una wait_callback come per eventlet/gevent/uWsgi ci vorrà un wrapper che utilizzi psycopg in maniera async (non green) ed offra un'interfaccia simil-dbapi ma non bloccante e con tutti gli yeldini al posto loro. -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Il giorno 14 marzo 2014 18:12, Manlio Perillo manlio.peri...@gmail.com ha scritto: 2014-03-13 19:35 GMT+01:00 Balan Victor balan.vict...@gmail.com: Di recente ho letto un po di tornado, e in particolare mi sono soffermato sul modulo tornado.httpserver(Non-blocking HTTP server). Stando a quello che c'è scritto sulla documentazione ufficiale parla di non-blocking, single-threaded HTTP server e di risolvere il problemi di tipo C10K. Qua sembra interessante, anche se non ho la minima idea di come funzioni. [...] Detto questo, non riesco a capire l'utilità di un HTTP Server con performance elevatissime ma che non permetta una minima interazione con il database. Probabilmente sopra ho scritto delle cavolate ma mi mancano completamente le basi per questo tipo di argomenti e volevo capire meglio come funzionano e quali sono i campi di applicazione di tecnologie simili. L'argomento è complesso. hai da consigliare qualche post/documento/libero che spiega bene l'argomento?(Italiano/Inglese) ? Su google ne ho trovato alcuni ma non sono il massimo della chiarezza Nel caso di un server C10K ready ci sono due aspetti principali. Il primo riguarda tutto quel codice che esegue una richiesta ed aspetta una risposta. Il secondo riguarda il paradigma utilizzato per gestire il flusso del codice. Il 97.7% delle librerie disponibili fa qualcosa del tipo: status = send_request(data) resp = recv_response() Entrambe le funzioni potrebbero metterci molto tempo a completare, ma questo codice blocca l'intero thread fino a quando resp non è disponibile. Quello che fa tornado è di usare quelle che si chiamano coroutine, o threading cooperativo. In questo caso sia send_request che recv_response bloccano il flusso corrente del codice (la coroutine corrente), ma non l'intero thread perchè usando le coroutine viene effettuato un salto (simile al goto) che va ad eseguire altre funzioni coroutine. e se dentro recv_response ho una chiamata al db perché mi dovrebbe bloccare? se sono eseguiti in coruotine la chiamata al db non dovrebbe andare a girare in qualche modo in background? Senza le coroutine, quello che si fa è usare le callback ed una macchina a stati (lo stato deve essere gestito manualmente perchè non hai lo stack disponibile nel codice normale). L'esempio di prima diventa: def do_request(data, ctx): send_request(data, on_request_done, ctx) def on_request_done(status, ctx): recv_response(on_response_done, ctx) def on_response_done(resp, ctx): # DONE Come vedi diventa molto complicato, specialmente se ad esempio devi fare il parsing di un protocollo come HTTP (puoi vedere il codice di Twisted se ti interessa). Tra l'altro il motivo perchè tornado va di moda è perchè permette di avere il codice che è praticamente lo stesso di quello normale, ma che si comporta in modo completamente diverso. Twisted offre un framework per la programmazione asincrona da anni, ma non è mai stato di moda, perchè molto più difficile. Prima di arrivare a tornado sono passato da Twisted ma non mi sono soffermato troppo perché molto più difficile Considerato tutti i problemi che gli utenti hanno con tornado e friends (e che nemmeno sanno di sapere), direi che, come sempre, explicit is better than implicit. Il mio suggerimento è sempre quello di imparare prima le basi (vicino a quello che realmente succede) e solo dopo utilizzare cose che rendono la programmazione e manutenzione più semplice. Come ultima cosa: gevent (l'implementazione delle coroutine) sembra risolva tutti i problemi, ma in realtà tutto quello che fa ha un costo. Non è un caso che i web server C10K usano la programmazione tramite callback e macchina a stati; questo perchè è molto più efficiente nella gestione della memoria. Ogni coroutine è come un thread ed ha bisogno di memoria per lo stack, oltre poi al costo per il context switch. E i multiprocessing? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-14 18:12 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: Ogni coroutine è come un thread ed ha bisogno di memoria per lo stack, oltre poi al costo per il context switch. Rispetto ad un thread il costo è però pressochè nullo. Se non hai parti bloccanti che non riesci a rendere asincrone è di fatto l'approccio più performante e scalabile che puoi adottare. -- Giampaolo - http://grodola.blogspot.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-13 19:35 GMT+01:00 Balan Victor balan.vict...@gmail.com: Di recente ho letto un po di tornado, e in particolare mi sono soffermato sul modulo tornado.httpserver(Non-blocking HTTP server). Stando a quello che c'è scritto sulla documentazione ufficiale parla di non-blocking, single-threaded HTTP server e di risolvere il problemi di tipo C10K. Qua sembra interessante, anche se non ho la minima idea di come funzioni. Sono rimasto perplesso quando ho provato a cercare qualche ORM da usare con tornado e non ho trovato nulla. Dopo un po di ricerche, da quello che ho capito, un orm non è fatto per lavorare in maniera asincrona. E non ho neppure trovato una libreria per collegarsi a qualche tipo di database relazione(a parte quella con MySql ma sembra non più supportata). Detto questo, non riesco a capire l'utilità di un HTTP Server con performance elevatissime ma che non permetta una minima interazione con il database. Probabilmente sopra ho scritto delle cavolate ma mi mancano completamente le basi per questo tipo di argomenti e volevo capire meglio come funzionano e quali sono i campi di applicazione di tecnologie simili. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python Hai intravisto giusto a la domanda non è per niente stupida. I server asincroni performano e scalano enormemente meglio delle controparti basate su processi/thread multipli (un esempio lampante è pyftpdlib: https://code.google.com/p/pyftpdlib/wiki/Benchmarks - si guardi sopratutto l'utilizzo di memoria) a patto che, appunto, tu non blocchi. Quando arrivi al punto in cui sei costretto a bloccare (es: non hai uno strato apposito che interagisce col db in maniera asincrona) hai una sola possibilità: usare un thread (o un sottoprocesso). Fare questo significa essenzialmente ripassare la palla all'IO loop e quando il thread ha terminato prendere il risultato della funzione e processarlo. Fare questo a mano in maniera sana non è semplice, ed è infatti per questo che solitamente i framework ti mettono a disposizione interfacce apposite. Nel caso specifico di Tulip/asyncio il codice dovrebbe essere una cosa di questo tipo: from tulip import tasks, coroutine @coroutine def foo(): fut = self.run_in_executor(long_running_db_call) yield from tasks.wait(fut) ret = fut.result() La magia nel codice sopra sta nello yield from che letteralmente si legge come lancia long_running_db_call in un thread, vai a fare altro e ritorna qui quando il thread è terminato. Con Twisted l'approccio è diverso in quanto anzichè le coroutines utilizzi le callback ma il concetto che sta alla base è il medesimo (lancia il thread, vai a fare altro e processa il risultato del thread quando ha terminato): https://twistedmatrix.com/documents/12.2.0/core/howto/threading.html Con Tornado casualmente non ho mai avuto a che fare con parti bloccanti ma dando un'occhiata qui pare sia possibile in maniera analoga a tulip/asyncio: http://www.tornadoweb.org/en/stable/concurrent.html L'unico caso in cui non sceglierei l'asincrono è dove TUTTE le tue richieste sono bloccanti per un motivo o per un altro, nel qual caso avresti prestazioni/scalabilità uguali o minori (più probabile) rispetto a soluzioni nate espressamente per utilizzare il modello di concorrenza classico (thread / multi processi, esempio classico: django + gunicorn). -- Giampaolo - http://grodola.blogspot.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Daniele Varrazzo wrote: Purtroppo tulip non si integra bene con il supporto green di psycopg, perché è basato su yield Chissà come mai Guido ci tiene tanto a questa seccatura dello yield... con tutti gli yeldini al posto loro. E non solo lui, a quanto pare. Ecco ben spiegata la prospettiva di noi comuni mortali che bizzarramente ci teniamo così tanto ad avere tutti gli yeldini al posto loro. Unyielding - Deciphering Glyph https://glyph.twistedmatrix.com/2014/02/unyielding.html Che è poi il motivo per cui ho usato Twisted per anni, apprezzo Tornado (e Go), e non mi vedrete tanto presto a usare gevent, eventlet e compagnia, per non dire mai. -- Nicola Larosa - http://www.tekNico.net/ A plus sign is just a square with collapsed sides, after passing through a hash sign: ◽ # + (Where are my medications when I need them?) - Nicola Larosa, February 2014 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Non blocking http server e integrazione con database relazionali
Di recente ho letto un po di tornado, e in particolare mi sono soffermato sul modulo tornado.httpserver(Non-blocking HTTP server). Stando a quello che c'è scritto sulla documentazione ufficiale parla di non-blocking, single-threaded HTTP server e di risolvere il problemi di tipo C10K. Qua sembra interessante, anche se non ho la minima idea di come funzioni. Sono rimasto perplesso quando ho provato a cercare qualche ORM da usare con tornado e non ho trovato nulla. Dopo un po di ricerche, da quello che ho capito, un orm non è fatto per lavorare in maniera asincrona. E non ho neppure trovato una libreria per collegarsi a qualche tipo di database relazione(a parte quella con MySql ma sembra non più supportata). Detto questo, non riesco a capire l'utilità di un HTTP Server con performance elevatissime ma che non permetta una minima interazione con il database. Probabilmente sopra ho scritto delle cavolate ma mi mancano completamente le basi per questo tipo di argomenti e volevo capire meglio come funzionano e quali sono i campi di applicazione di tecnologie simili. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Forse questa discussione può aiutarti http://stackoverflow.com/questions/3638844/is-tornado-really-non-blocking Il giorno 13 marzo 2014 19:35, Balan Victor balan.vict...@gmail.com ha scritto: Di recente ho letto un po di tornado, e in particolare mi sono soffermato sul modulo tornado.httpserver(Non-blocking HTTP server). Stando a quello che c'è scritto sulla documentazione ufficiale parla di non-blocking, single-threaded HTTP server e di risolvere il problemi di tipo C10K. Qua sembra interessante, anche se non ho la minima idea di come funzioni. Sono rimasto perplesso quando ho provato a cercare qualche ORM da usare con tornado e non ho trovato nulla. Dopo un po di ricerche, da quello che ho capito, un orm non è fatto per lavorare in maniera asincrona. E non ho neppure trovato una libreria per collegarsi a qualche tipo di database relazione(a parte quella con MySql ma sembra non più supportata). Detto questo, non riesco a capire l'utilità di un HTTP Server con performance elevatissime ma che non permetta una minima interazione con il database. Probabilmente sopra ho scritto delle cavolate ma mi mancano completamente le basi per questo tipo di argomenti e volevo capire meglio come funzionano e quali sono i campi di applicazione di tecnologie simili. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python -- Shipping is a feature. A really important feature. Your product must have it. Rendete ogni cosa il più semplice possibile, ma non di più (Albert Einstein) You are what you choose today, not what you've chosen before Unix IS user friendly. It's just selective about who its friend are ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Il giorno 13 marzo 2014 19:40, Francesco Pischedda francesco.pische...@gmail.com ha scritto: Forse questa discussione può aiutarti http://stackoverflow.com/questions/3638844/is-tornado-really-non-blocking avevo già visto questa discussione però più che chiarirmi mi ha confermando che l'interazione con il db porta a bloccare tutte le altre connessioni. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Il giorno 13 marzo 2014 20:41, Balan Victor balan.vict...@gmail.com ha scritto: Il giorno 13 marzo 2014 19:40, Francesco Pischedda francesco.pische...@gmail.com ha scritto: Forse questa discussione può aiutarti http://stackoverflow.com/questions/3638844/is-tornado-really-non-blocking avevo già visto questa discussione però più che chiarirmi mi ha confermando che l'interazione con il db porta a bloccare tutte le altre connessioni. quello che non capisco è a che pro avere un server che gestisce 10k di connessioni se poi non puoi creare una pagina dinamica? per servire solo delle pagine statiche? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
in che senso non puoi creare una pagina dinamica? cosa te lo impedisce? Il giorno 13 marzo 2014 20:46, Balan Victor balan.vict...@gmail.com ha scritto: Il giorno 13 marzo 2014 20:41, Balan Victor balan.vict...@gmail.com ha scritto: Il giorno 13 marzo 2014 19:40, Francesco Pischedda francesco.pische...@gmail.com ha scritto: Forse questa discussione può aiutarti http://stackoverflow.com/questions/3638844/is-tornado-really-non-blocking avevo già visto questa discussione però più che chiarirmi mi ha confermando che l'interazione con il db porta a bloccare tutte le altre connessioni. quello che non capisco è a che pro avere un server che gestisce 10k di connessioni se poi non puoi creare una pagina dinamica? per servire solo delle pagine statiche? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python -- Shipping is a feature. A really important feature. Your product must have it. Rendete ogni cosa il più semplice possibile, ma non di più (Albert Einstein) You are what you choose today, not what you've chosen before Unix IS user friendly. It's just selective about who its friend are ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
On 13/03/2014 20:55, Francesco Pischedda wrote: cosa te lo impedisce? di quotare bene? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Il giorno 13 marzo 2014 19:35, Balan Victor balan.vict...@gmail.com ha scritto: E non ho neppure trovato una libreria per collegarsi a qualche tipo di database relazione Per postgres c'è momoko ( http://momoko.61924.nl/en/latest/index.html ) che wrappa psycopg2 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Il giorno 13 marzo 2014 20:55, Francesco Pischedda francesco.pische...@gmail.com ha scritto: in che senso non puoi creare una pagina dinamica? cosa te lo impedisce? Da dove carico i dati se non dal DB? Per postgres c'è momoko ( http://momoko.61924.nl/en/latest/index.html ) che wrappa psycopg2 lo sto guardando adesso ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
