<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-03-12 15:39 GMT+00:00 Marco Ippolito <span dir="ltr"><<a href="mailto:ippolito.marco@gmail.com" target="_blank">ippolito.marco@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">grazie Matteo delle tue info<br>
io propenderei per Gearman (appunto perchè tra l'altro<br>
multi-linguaggio) ma in questa pluralità di tool....mi perdo))))</blockquote><div><br></div><div>Il problema e' che tu non hai spiegato esattamente cosa vuoi fare. A seconda di quello che vuoi fare una soluzione puo' essere meglio di un'altra.</div><div><br></div><div>Io Celery lo misi in produzione qualche mese fa. E fu un bagno di sangue. Tra l'altro Celery + Redis funziona bene sulla carta, ma spera sempre di tenere tutto su un'unica macchina (che vuole dire che i tuoi host devono essere, almeno dal punto di vista di celery, shared nothing). </div><div><br></div><div>Celery tende a fregare. Uno crede di farsi tutti i suoi task come "gestione del flusso", ma invece deve pensare di scrivere un sistema distribuito, dal punto di vista dei trade off. *Anche* se sta tutto su una macchina. Per esempio ogni volta che due task si passano roba, questa roba viene serializzata e deserializzata in redis (o in chi per lui). Anche se, formalmente, i due task potrebbero passarsela in memoria. Quindi... task piccoli funzionano non troppo bene, specie se la mole dei dati che si passano non e' piccola. </div><div><br></div><div>Ci sono una serie di scelte discutibili: per esempio i risultati dei task restano di default nel database per sempre (guarda un po' cosa succede dopo un po'.... ricorda che redis deve sempre tenere tutto il dataset in memoria).</div><div><br></div><div>Un sacco di edge case che abbiamo trovato non sono documentati bene (ovvero, la documentazione e' perfetta per fare quattro minchiate, se ne fai cinque puoi sperare che qualcuno su SO risponda -- a volte si e a volte no -- oppure leggere i sorgenti). Ora celery e' anche piccolino, ma dipende da altre due librerie che piccoline non sono e il modo in cui si incrociano non e' banale.</div><div><br></div><div>Poi... non tutti i tipi di worker sono auto-restartabili. Per lo meno a sentire la documentazione. </div><div><br></div><div>Tieni anche d'occhio cosa succede se tieni stato persistente in Redis. </div><div><br></div><div>Celery e' un altro nome per "siccome Python liscio e concorrenza non vanno troppo d'accordo, mettiamo su un sistema relativamente complicato come cerotto". Poi si... ci sono anche casi in cui vuoi qualcosa come celery. Ma davvero... </div></div><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>