<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-01-30 14:20 GMT+00:00 Daniele Palmese <span dir="ltr"><<a href="mailto:palmux@gmail.com" target="_blank">palmux@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Il giorno 30 gennaio 2015 14:45, enrico franchi <span dir="ltr"><<a href="mailto:enrico.franchi@gmail.com" target="_blank">enrico.franchi@gmail.com</a>></span> ha scritto:<span class=""><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span></span><div>State misurando *performance* su un sistema che non provate a fare scalare (visto che hw e' fisso). In pratica siete nel caso piu' favorevole possibile per node.js. I punti principali di debolezza di node li avete completamente esclusi dal test. E per inciso, non necessariamente Python e' la scelta "giusta".</div></div></div></div></blockquote><div><br></div></span><div>Quindi dovrebbe vincere a mani basse Node.js se siamo in ambiente favorevole, voglio solo verificare con mano. Ripeto è un test che di attendibilità ha veramente il giusto.<br></div></div></div></div></blockquote><div><br></div><div>Ammesso che chi lo usa lo sappia usare, si. Si potrebbero sempre impiccare con le loro mani; ma diciamo che a meno di grosse cazzate dovrebbero farcela facile. Anche perche', appunto, il setup di Python non e' particolarmente efficiente sulla carta *e* vi interessano quasi solo le performance.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>Considera che le risorse hardware a disposizione sono volutamente bassine e quindi uno degli aspetti che mi incuriosiscono, la gestione della cpu, potrebbero mandare in crisi tutto. Sul fatto che Python potrebbe non essere la scelta giusta convengo, viene usato soprattutto per familiarità. <br></div></div></div></div></blockquote><div><br></div><div>Si appunto, il che da un enorme vantaggio (specie se la metrica che usate sono le req/s o qualcosa di simile) a node. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Tu cosa avresti usato come piattaforma di paragone?<br></div><span class=""><div><br></div></span></div></div></div></blockquote><div><br></div><div>Io avrei prima di tutto cercato di capire come fare il test (e capire cosa volete misurare). Cioe' se il punto e' vedere se node.js fa piu' req/s di Django, la risposta e' scontata: si. L'unico caso in cui potete ribaltare il tutto e' studiando dei task misti CPU bound e IO bound. A quel punto andate a giocare dove node.js se la cava male e dove Django... beh, non e' che se la cava bene, ma e' un pochetto piu' agnostico sulla questione. Se poi il task CPU bound e' qualcosa per la quale Python ha delle signore librerie e node non ce le ha... beh, hai un po' ribaltato la questione.</div><div><br></div><div>Il fatto e' che le performance a scatola chiusa a me non interessano (ovvero, i miei problemi di performance sono sufficientemente critici per cui soluzioni prefabbricate non interessano e devo lavorare molto a livello di architettura). Finche' cercate di fare il solito benchmark sulle richieste o simili, al meglio otterrete gli stessi risultati noti. Node.js e' molto veloce. Su Python puoi combinare qualcosa di buono facendo tuning dei vari tornado o magari gunicorn (ma se usato in modo asincrono) etc etc etc. E li ci si avvicina molto a node.js. Poi tiri in campo Go e mandi a casa tutti quanti.</div></div><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>