Al diseñar una cola de trabajos, ¿qué debería determinar el alcance de un trabajo?

7

Tenemos un sistema de cola de trabajos que procesará alegremente cualquier tipo de trabajo que se le otorgue. Tenemos la intención de usarlo para procesar trabajos que contienen 2 tareas:

  • Trabajo (pasar información de un servidor a otro)
    • Recuperar tarea (obtener los datos, lentamente)
    • Enviar tarea (enviar los datos, comparativamente rápido)

La dificultad que tenemos es que no sabemos si dividir las tareas en trabajos separados o procesar el trabajo de una sola vez.

¿Existen buenas prácticas o referencias útiles sobre este tema? ¿Hay algún beneficio obvio de un método que nos falta?

Hasta ahora podemos ver estos beneficios para cada método:

Split

  • La duración del alquiler del trabajo refleja la duración del trabajo: en lugar del total de dos
  • Granularidad más fina en la recuperación: si perdemos la conectividad saliente, podemos decirles a todos que vuelvan a intentarlo
  • El estado de inicio de la segunda tarea se guarda en el historial de tareas: ayuda con la depuración (aunque se podría agregar un registro similar en el método de una sola tarea)

Single

  • Un solo trabajo para ser programado: Menos gastos de procesamiento
  • Los datos no están obsoletos en la recuperación: si el tiempo de inactividad saliente es bastante largo, los trabajos pendientes de envío podrían estar desactualizados
pregunta Stu Pegg 04.07.2012 - 12:11

3 respuestas

7

¿Cuál de estos representa la adición mínima útil al trabajo que realiza su aplicación? Por lo general, opino que un trabajo en una cola debe representar una unidad de trabajo útil: ya sea que se complete o cancele, debe terminar con el sistema en un estado coherente.

Esa situación se define principalmente por su dominio de problemas, por lo que no es algo para lo que exista una respuesta general. A veces hay limitaciones arquitectónicas que te obligan a dividir el trabajo de maneras no naturales. Un ejemplo es en una aplicación GUI, donde probablemente tenga como objetivo realizar todo el trabajo de su aplicación de forma simultánea, pero luego actualizar la interfaz de usuario en un subproceso dedicado. Eso significa que tienes que dividir tu trabajo ("hacer algo útil y mostrarle al usuario que lo hice") en esos dos pasos ("hacer algo útil y mostrarle al usuario que lo hice"). De hecho, en este caso no es un gran problema, ya que si la aplicación se cierra antes de actualizar la interfaz de usuario, es probable que el usuario no quiera conocer el trabajo que has realizado de todos modos.

Si la "adición mínima útil" es demasiado pequeña, entonces pienso en agruparlos para reducir la cantidad de tiempo empleado en la sobrecarga de envío de trabajos. Esta definición de "demasiado pequeño" es algo que requiere medición para su trabajo y en su entorno; depende más de la arquitectura que de su problema. Perfile su aplicación: si está gastando una cantidad significativa de tiempo agregando y eliminando cosas de las colas o creando y destruyendo subprocesos, está haciendo muy poco trabajo en cada operación.

    
respondido por el user4051 05.07.2012 - 21:00
4

En primer lugar: ¿por qué estas tareas de recuperación y envío se combinan de todos modos?

Si, de todos modos, dependen uno de otro (use los datos del otro o deben procesarse en un cierto orden), el "Trabajo" debe ser atómico, mantenerse y procesarse en conjunto dentro del nodo.

Por otra parte, si el "Trabajo" es la representación de una unidad de comunicación en el lado del receptor (como cuando los nodos recopilan las tareas entrantes y salientes en colas al otro nodo, y las vacían regularmente), entonces es justo un grupo de tareas independientes que ahora contienen dos elementos. En este caso, debe dividir el "Trabajo" (y cambiar su nombre a Sobre :-)), y registrar las tareas individualmente en la cola de trabajos.

La optimización del rendimiento para la gestión de colas puede esperar hasta problemas reales. En un entorno de procesamiento de colas paralelo, tener un núcleo trabajando en un gran trabajo mientras que los otros núcleos están inactivos es menos eficiente (y más difícil de escalar) en comparación con la sobrecarga relativamente pequeña de una mayor administración de colas.

    
respondido por el Lorand Kedves 06.07.2012 - 12:40
2

Desde mi punto de vista, dividir un trabajo podría ser una mejor opción. Sí, se agrega a la complejidad, pero también tiene sus propias ventajas. Si tiene un sistema de procesamiento de colas, en algún momento tendrá varios trabajos en cola que requieren una programación para un mejor rendimiento.

Los sistemas de un solo trabajo generalmente tienen mayores tiempos de espera para los procesos que llegan más tarde en la cola. Es posible que también tenga que dar prioridad a algunos trabajos sobre otro (programación de prioridad). En resumen, la programación es eficiente si un trabajo tiene sub-etapas. Como mencionó, también tiene un mejor modelo de recuperación y los estados podrían manipularse fácilmente.

    
respondido por el tnx1991 13.07.2012 - 11:03

Lea otras preguntas en las etiquetas