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

[Roberto De Ioris]

> 2014-03-16 19:40 GMT+01:00 Roberto De Ioris <roberto a 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