[Python] Non blocking http server e integrazione con database relazionali

[Manlio Perillo]

2014-03-17 11:22 GMT+01:00 Roberto De Ioris <roberto a 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
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20140317/205818c8/attachment-0001.html>