<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-08-26 14:39 GMT+01:00 Carlos Catucci <span dir="ltr"><<a href="mailto:carlos.catucci@gmail.com" target="_blank">carlos.catucci@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"><span class=""><div><br></div></span><div>Enrico il problema e' sempre di unita' di misura. Il progetto piu' piccolo a cui lavori tu e di qualche "anno luce" piu' grande del piu' grande a cui lavoro io. </div></div></div></div></blockquote><div><br></div><div>Ma non e' questo il problema... spiego meglio.</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>Per me impiegare tempo ad apprendere come fare in Go le cose che faccio con Python e Django/Flask e' una "spesa" che non posso affrontare ora. </div></div></div></div></blockquote><div><br></div><div>E questo e' chiaro (in realta' lo e' per tutti).</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>Pero' se mi trovo (come potrei se il progetto a cui sto lavorando vede la luce) a dover fare cose che in Python non "vengono bene", esempio gestire qualche migliaio di messaggi "conteporanei" provenienti da altrettanti router sparsi qua e la, ecco che una routine Go, meglio se wrappabile, mi puo' risolvere la cosa senza che io debba impazzire. <br></div></div></div></div></blockquote><div><br></div><div>E io quello che ti sto dicendo e' che a fare questo il "supermetodo" ficcato nell'infrastruttura Python esistente non e' una buona idea.</div><div><br></div><div>Allora, parliamo della tua infrastruttura attuale. Hai un db in cui scrivi e da cui leggi. Avrai una webapp che legge dal db per "vedere cose". Dopo di che hai bisogno di un coso che riesca a ricevere molte scritture e le metta nel db. Da quello che ho capito, la lettura non e' un problema veramente critico (relativamente pochi operatori dovranno leggere i dati, immagino tramite pagine web). Il problema e' l'ingestion dei dati. </div><div><br></div><div>Quindi lasciamo completamente perdere la webapp per leggere (che stara' in Python e tanti saluti). Tu devi progettare un coso veloce che prende, immagino delle gran POST (o PUT) e ficca dati corrispondenti nel DB. Ora, cosa succede ad una put?</div><div><br></div><div>Avrai immagino un loadbalancer di qualche tipo (o reverse proxy che dir si voglia) che prende una chiamata HTTP. Questa chiamata verra' mandata ad un webserver che la deve processare. Il webserver dovra' capire che la deve passare attraverso qualche trasporto alla webapp che la processera' (e.g., wsgi) -- questo tipicamente coinvolge anche copiare dei buffer dal webserver al worker della webapp --, il tuo coso dietro poi prende la richiesta, la smonta (che so, parsa del json), pesca i dati che servono e li passa al driver del db che a sua volta scrive sul db. Verosimilmente questa operazione e' bloccante. Il che vuole dire che se hai troppa concorrenza finisci i worker e cominci a tirare dei 503. E perdi dati. Male.</div><div><br></div><div>La tua idea di "riscrivere il magic method in Go" probabilmente rende un po' piu' veloce il processamento dei dati (ma in compenso hai eventualmente il problema di convertire gli stessi dal formato pythonoso che ricevi in input e che quando il tuo handler viene chiamato sono gia' stati macinati e li passi al metodo in Go, che poi parlera' con il db. Ora si pone il problema di come fare in modo asincrono la richiesta al db (questo e' il pezzo piu' interessante). Hai diversi approcci... e scegliere quello giusto (per come funziona Go) e' il punto chiave del successo.</div><div><br></div><div>In tutto questo dal punto di vista delle ops, non ho idea di cosa cavolo succeda. Per esempio non ho idea come un worker django si senta quando gli crei sotto dei thread sotto le chiappe (questo fa il runtime di Go). Non ho idea di *quando* li crei. Per esempio, se venissero creati appena carichi la libreria condivisa, che verosimilmente potrebbe accadere *prima* che i worker vengano forkati, ti troveresti potenzialmente con un runtime rotto (i thread non sono copiati su una fork). Non so se il runtime di Go gestisce questa cosa quando la fork la fa Python "da fuori". Nota che proprio il problema delle interazioni fra fork e posix non e' banale ed e' uno dei motivi per cui in Go non hai una vera e propria fork (ma solo un "subprocess") e in Python rischi di brutto quando fai fork + thread (con risultati disastrosi garantiti se hai la pretesa di fare anche logging).</div><div><br></div><div>Quello che voglio dirti e' che vai a mettere su un sistema significativamente complesso, in cui devi capire molto di piu' di diverse parti in movimento, con alcuni pezzi specialmente immaturi (non credo che ci siano molti sistemi in produzione che servono Go tramite una libreria condivisa da Python). Secondo me e' una situazione in cui prima o poi qualcosa si spacca e non e' chiaro perche'.</div><div><br></div><div>Se il tuo problema e' "devo gestire tante scritture concorrenti"... beh, vai su una situazione Go pura. </div><div><br></div><div>Intanto... dimenticati un ORM (mi sembra di avere capito che hai problemi di performance, e un use case relativamente semplice: input in tabelle ben definite). Se proprio lo vuoi, ce lo hai anche in Go. Ma potrebbe finire per essere un collo di bottiglia (in Python come in Go). </div><div><br></div><div>La webapp la puoi scrivere in Go puro. Ci sono parecchie librerie di alto livello per fare sta roba: ti trovi con un binarietto che devi tenere eseguito che ascolta sulla porta che vuoi e ti prende tutte le post del mondo. Non devi copiare dati avanti e indietro dal webserver al worker (o usare qualunque tecnica "smart" che i webserver usano oggi). Gestisci la concorrenza come vuoi: tipicamente una goroutine per richiesta e tanti saluti: il tuo modello e' sufficientemente semplice che anche una tecnica del genere dovrebbe funzionare. </div><div><br>E' roba *semplice*. E' piu' semplice che imparare abbastanza Go da fare il super-metodo e poi imparare come fare parlare Python e Go.</div><div><br></div><div><br></div><div><br></div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>