<br><br><div class="gmail_quote">2011/12/2 Alessandro Dentella <span dir="ltr"><<a href="mailto:sandro@e-den.it">sandro@e-den.it</a>></span></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


un cliente mi ha chiesto di aiutare a capire come rendere pił veloce una<br>
applicazione web che raccoglie dati da molti utenti differenti in<br>
contemporanea (qualche centinaio) e si ingolfa in particolari momenti<br>
del mese di maggior accesso.<br></blockquote><div><br></div><div>Ora bisogna capire cosa devi fare con questi dati e quanti dati. Perche' "di per se'" "qualche centinaio" non e' molti.</div>

<div>Nota che la questione e' rilevante: e' ovvio che tu hai un problema di performance (perche' lo dici) ma i numeri che riporti non dovrebbero darlo.</div><div>A meno che il problema non sia altrove (e.g., questi ~ 400 utenti postano una vagonata di update al secondo, devi fare conti molto pesanti sui loro dati, hai tempi di risposta brevissimi, quasi rt).</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Attualmente usano Tornado [1], un incrocio fra un server web ed un piccolo<br>
framework (che tramite un decoratore permette di rendere una funzione<br>
asincrona).<br></blockquote><div><br></div><div>Qui potrei vedere una radice del problema. Non c'e' nulla che (in Python) possa "rendere una funzione asincrona *e* buon cittadino di un framework asincrono.</div>

<div><br></div><div>@asyn</div><div>def foo(...)</div><div>    for x in range(1000):</div><div><div>        for y in range(10000):</div></div><div><div>            for z in range(1000):</div></div><div>                ...</div>

<div><br></div><div>per esempio ti inchiodera' irrimediabilmente il tutto. E' vero che la funzione ritorna subito, ma prima di avere il risultato lei si prende comunque tutto il tempo necessario. Quindi non c'e' un decoratore che puo' risolvere automaticamente il problema.</div>

<div><br></div><div>Questo e' ovviamente ovvio per te, ma e' meglio chiarirlo comunque. Se per caso hai una situazione come quella di sopra, si puo' pensare a come risolverla (ma ci vogliono piu' dettagli). </div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Non ho alcuna esperienza di Tornado, qualche esperienza con twisted e<br>
qualche dubbio sul fatto che quel particolare problema abbia grandi vantaggi<br>
dall'approccio asincrono.</blockquote><div><br></div><div>A me sembra invece proprio uno dei casi in cui e' vincente. Ovviamente *a meno che* tu non debba fare conti pesanti.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

 L'applicazione lato client usa intensamente ajax e<br>
molte chiamate al server che fanno pochi conti ed una manciata di select<br>
semplici o di piccole join.</blockquote><div><br></div><div>Sembrerebbe di no.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> La macchina ha 4 processori e 4 GB di RAM<br>


(principalmente libera). Ogni chiamata dallo stesso client cambia dati nella<br>
sessione che devono quindi essere sincronizzati fra una chiamata e l'altra.<br></blockquote><div><br></div><div>Guarda, a naso per come hai descritto il problema non darebbe problemi al mio portatile.</div><div>Probabilmente c'e' qualcosa che ci sfugge.</div>

<div><br></div></div><br clear="all"><div><br></div>-- <br> .<br>..: -enrico-<br>