¿Tiene sentido usar un grupo de Actores?

Question

Estoy aprendiendo, y realmente me gusta, el patrón Actor. Estoy usando Scala en este momento, pero estoy interesado en el estilo arquitectónico en general, ya que se usa en Scala, Erlang, Groovy, etc.

El caso en el que estoy pensando es en donde necesito hacer las cosas concurrentemente, como, digamos "ejecutar un trabajo".

Con roscado, me gustaría crear un grupo de subprocesos y una cola de bloqueo, y que cada sondeo de la cola de hilo de bloqueo, y procesar los trabajos a medida que entraba y salía de la cola.

Con actores, ¿cuál es la mejor manera de manejar esto? ¿Tiene sentido crear un grupo de actores, y de alguna manera enviarles mensajes conteniendo o los trabajos? ¿Quizás con un actor "coordinador"?

Nota: Un aspecto del caso, que se me olvidó mencionar fue: ¿y si quiero limitar el número de puestos de trabajo mi aplicación procesará simultáneamente? Tal vez con una configuración de configuración? Estaba pensando que un grupo podría hacer que sea más fácil hacer esto.

Gracias!

Answer 1

A veces, tiene sentido limitar el número de procesos de trabajo que haya que operan simultáneamente en una lista de tareas grande, ya que la tarea del proceso se genera para completar implicar la asignación de recursos. Por lo menos, los procesos agotan la memoria, pero también pueden mantener abiertos los archivos y/o conectores que tienden a limitarse a solo miles y fallan miserablemente e impredecibles una vez que se agotan.

tener una piscina tarea tirón impulsada, uno puede generar N procesos vinculados que piden una tarea, y una parte de ellos una función que pueden spawn_monitor. Tan pronto como el proceso supervisado haya terminado, vuelven para la siguiente tarea. Las necesidades específicas manejan los detalles, pero ese es el esquema de un enfoque.

La razón por la que dejaría que cada tarea generar un nuevo proceso es que los procesos tienen algún estado y es agradable para empezar una pizarra limpia. Es un ajuste común establecer el tamaño mínimo de almacenamiento dinámico de los procesos para minimizar el número de GC necesarios durante su vida útil. También es una recolección de basura muy eficiente para liberar toda la memoria de un proceso y comenzar una nueva para la próxima tarea.

¿Se siente raro usar el doble de procesos así? Es una sensación que debes superar en la programación de Erlang.

Answer 2

una piscina es un mecanismo que se utiliza cuando el costo de crear y derribar un recurso es alta. En Erlang, este no es el caso, por lo que no debe mantener un grupo.

Debe generar procesos a medida que los necesita y destruirlos cuando haya terminado con ellos.

Answer 3

No existe la mejor manera para todos los casos. La decisión depende del número, la duración, la llegada y el tiempo requerido de finalización de los trabajos.

La diferencia más obvia entre simplemente destetar actores y usar pools es que en el primer caso sus trabajos se terminarán casi al mismo tiempo, mientras que en el último caso los tiempos de finalización se extenderán en el tiempo. Sin embargo, el tiempo promedio de finalización será el mismo.

La ventaja de utilizar actores es la simplicidad en la codificación, ya que no requiere manipulación adicional. La desventaja es que tus actores compiten por los núcleos de tu CPU.No podrá tener más trabajos paralelos que los núcleos de CPU (o HT's, lo que sea), independientemente del paradigma de programación que utilice.

Como ejemplo, imagine que necesita ejecutar 100'000 trabajos, cada uno con un minuto, y los resultados vencen el próximo mes. Tienes cuatro núcleos. ¿Engendrarías 100.000 actores que competirían por los recursos durante un mes o harías cola en tus trabajos y ejecutarías cuatro a la vez?

Como contraejemplo, imagina un servidor web ejecutándose en la misma máquina. Si tiene cinco solicitudes, ¿preferiría atender a cuatro usuarios en tiempo T, y uno en 2T, o servir los cinco en tiempo de 1.2T?