> 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