<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-03-16 19:40 GMT+01:00 Roberto De Ioris <span dir="ltr"><<a href="mailto:roberto@unbit.it" target="_blank">roberto@unbit.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">[...]<br>
> Le alternative che *io* vedo sono tutte architetturali, ovvero mettersi<br>
> nell'ordine di idee di avere un pool di worker fuori dall'app web e<br>
> delegare quasi ogni cosa li.<br>
<br>
<br>
</div>Che sono le stesse che propongo io, django riceve la richiesta, fa tutti i<br>
controlli del caso (come l'autenticazione) e poi passa la connessione (o<br>
tramite proxy o tramite fd-passing su socket unix) al backend gevent che<br>
continua a gestire la sessione liberando django.<br><br></blockquote><div>Forse mi sono perso qualcosa, ma quale è la differenza tra questa soluzione ed avere Apache prefork con N + M processi?</div><div><br></div><div>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).</div>
<div><br></div><div>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?</div><div><br>
</div><div> <br></div></div>Ciao  Manlio</div></div>