Hit #1

Operador de Sobel

Se implementó un servicio que divide la imagen en N segmentos según el parámetro partes. Cada segmento se envía en paralelo a diferentes workers (a través de RabbitMQ), donde cada worker aplica el filtro de Sobel de forma concurrente. Una vez procesados, el maestro unifica los segmentos respetando su posición original y genera la imagen final resultante.

Flujo de ejecución para testeo

1. Descargar el source code del hit 1:

2. Construir el proyecto Maven sin ejecutar tests:

   cd master
   mvn clean package -Dskiptests
   cd ..

3. Iniciar los contenedores Docker:

   docker-compose up --scale worker=<cantidad de workers a levantar>

4. Esperar a que los workers esten listos.

5. Enviar la imagen a procesar (por ejemplo, con Postman):

   • Método: POST a http://localhost:8080/task/processAndPublish
   • Parámetro partes: número de segmentos en que dividir la imagen
   • Body: form-data con:
     • Key: image (archivo de imagen a procesar)

6. La imagen aparece con el filtro sobel aplicado dentro de ./output

Comparativa de Rendimiento Sobel

Tamaño Imagen	Workers	Partes	Publicado en Cola	Fin Proceso	Tiempo Total
3 MB	1	9	16:05:16	16:05:19	3 seg
15 MB	1	9	15:42:59	15:43:06	7 seg
30 MB	1	9	16:07:21	16:07:28	7 seg
3 MB	9	9	16:01:45	16:01:46	1 seg
15 MB	9	9	15:57:33	15:57:42	9 seg
30 MB	9	9	16:00:14	16:00:20	6 seg

Conclusiones

• Efecto de paralelismo en imágenes pequeñas: Para la imagen de 3 MB, pasar de 1 worker a 9 reduce significativamente el tiempo de procesamiento (de 3 seg a 1 seg), demostrando que el overhead de distribución es pequeño comparado con la mejora por concurrencia.
• Sobrecarga en tamaños medios: Para la imagen de 15 MB, el procesamiento distribuido con 9 workers tarda más (9 seg) que la versión secuencial con 1 worker (7 seg). Esto sugiere que el costo de dividir y coordinar tareas supera el beneficio del paralelismo en tamaños intermedios.
• Balance en imágenes grandes: Para la imagen de 30 MB, el enfoque distribuido con 9 workers presenta una ligera mejora (6 seg) frente a la ejecución secuencial (7 seg), indicando que a mayor tamaño de datos, el paralelismo comienza a compensar el overhead de orquestación.
• Recomendación de configuración: Según el tamaño de las imágenes y la infraestructura, conviene:
  • Usar múltiples workers para imágenes pequeñas (< 5 MB) para maximizar rendimiento.
  • Evaluar caso a caso para imágenes de tamaño medio (≈ 15 MB), pues el overhead puede penalizar.
  • Implementar distribución para imágenes grandes (> 25 MB) donde la ganancia paralela justifica la coordinación.