<div class="gmail_quote">2010/10/13 mipassa <span dir="ltr"><<a href="mailto:mipassat@gmail.com">mipassat@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Cierto todo lo que dices. Pero mi problema podría tratar por ejemplo de<br>
sondear estado de 100K equipos, que mientras llegas o no, te da timeout, y<br>
demás tiempo muertos, estas pasando a los otros 99.999. La cosa es llenar<br>
esos tiempos muertos con algo/thread ocioso y que no haya que estar creando<br>
continuamente costosos hijos/forks/procesos<br><br></blockquote><div><br></div><div> </div><div>Más que Perl o Java, creo que 100K threads es una misión para Erlang! :)</div><div><br></div><div>En todo caso, crear 100K threads, forks, o lo que sea, simultáneos es una barbaridad en cualquier lenguaje conocido. Incluso Erlang.</div>
<div> </div><div>En Perl, yo optaría por un pool de x workers utilizando alguno de los excelentes paquetes ya mencionados en esta conversación. </div><div><br></div><div>O incluso Gearman, que tiene excelente integración con Perl, es muy eficiente y muy escalable, y así repartes el trabajo entre varios nodos. Repartir el trabajo entre servidores y levantar workers es, IMHO, la única forma eficiente de hacer 100K "cosas" a la vez. Por supuesto, los workers van siempre en proporción a la capacidad de la máquina. </div>
<div><br></div><div>-r</div><div><br></div><div><br></div></div>