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