[Python-es] Envío de mensajes a múltiples destinos

[Alberto Valverde]

Alberto Valverde wrote:
> Jesus Cea wrote:
>> Antonio Beamud Montero wrote:
>> |> De hecho los threads serían muy eficientes, porque solo están
>> |> interesados en un socket cada uno y no usan select.
>> |
>> | Crear y destruir hilos por conexión es muy pesado.. para pequeños
>> | sistemas va bien, pero si crecen los requisitos, escala mal..
>>
>> En Solaris crear un hilo es muy ligero. Por otro lado, no he dicho que
>> se creen cuando llegan conexiones. Puedes usar un "pool".
>>
>> Mira Apache 2.2, por ejemplo.
>>
>> | ¿Te refieres a que es trivial programar con hilos vs programar un
>> | sistema asíncrono (twisted)?
>> |
>> | Todo depende, yo la mejor combinación la obtuve con twsited (epoll) +
>> | hilos (para las tareas que requerian más procedimiento). Con el tiempo,
>> | veo más trivial programar asincronamente que con hilos.
>>
>> Te pongo un ejemplo: si una peticion requiere que vayas a una base de
>> datos, con hilos puedes permitir bloquear ese hilo mientras esperas que
>> la base de datos responda. Con Twisted tienes que integrar la
>> comunicacion con la base de datos en el framework, so pena de que se te
>> bloquee todo mientras "alguien" está esperando por la base de datos.
>>
>> Además, puedes usar todos los módulos. Por ejemplo, puedo mandar un
>> email con "smtplib" como siempre, sin temer que el rendimiento caiga
>> para el resto.
>>
>> O, sencillamente, puedo realizar un cálculo matemático muy largo y
>> complejo o generar un gráfico que me lleva varios segundos, sin
>> penalizar al resto de hilos. Esto no lo puedes hacer en twisted sin que
>> tu código ceda el control al framework *explícitamente* cada poco tiempo.
>>
>> Lo lamento, pero Twisted no me gusta nada :). Y sí, sé bien que los
>> threads no son la panacea. Algún día pondré mis ideas por escrito... :-)
> 
> Estoy totalmente de acuerdo con que el paradigma de los hilos es más
> natural ya que "es lo suyo", que el sistema operativo se encargue de
> gestionar la multitarea y no obligue a las aplicaciones a ceder el
> control cooperativamente. Sin embargo, tal y como están las cosas, por
> lo menos en linux (no conozco solaris), no es factible tener un número
> muy alto de hilos del S.O concurrentes atendiendo a cada conexión, una a
> una. Hay un momento en el que se acaba la memoria :)
> 
> Entiendo que se busquen soluciones a nivel de aplicación; enrevesadas
> algunas (twsited ;) o de hilos ultra-ligeros (erlang, stackless...)

Me acabo de acordar de ésta comparación entre yaws (servidor web escrito
en erlang con hilos a nivel de vm) y apache con el worker mpm (hilos a
nivel de SO). El benchmark parece diseñado para favorecer a yaws
(¡¿clientes haciendo peticiones a un caracter cada 10 segundos?!) pero
da una idea de la diferencia de escalabilidad (ie: número de conexiones
simultaneas)

http://www.sics.se/~joe/apachevsyaws.html

Alberto