Tareas de C# TPL - Cuántas a la vez

Question

Estoy aprendiendo a usar el TPL para la parametrización de una aplicación que tengo. La aplicación procesa archivos ZIP, extrayendo todos los archivos que se encuentran dentro de ellos e importando los contenidos en una base de datos. Puede haber varios miles de archivos comprimidos esperando procesarse en un momento dado.

¿Tengo razón al comenzar una tarea separada para cada uno de estos archivos ZIP o es una forma ineficiente de usar el TPL?

Gracias.

Answer 1

Parece un problema más apropiado para hilos de trabajo (hilo separado para cada archivo) administrado con ThreadPool en lugar de TPL. TPL es excelente cuando puedes dividir y conquistar en un único elemento de datos, pero tus archivos zip se tratan individualmente.

E/S de disco va a ser el cuello de su botella, así que creo que tendrá que reducir el número de trabajos que se ejecutan simultáneamente. Es fácil de manejar esto con hilos de trabajo, pero no estoy seguro de cuánto control tienes (si es que no) sobre el paralelo para, foreach en cuanto a cómo el paralelismo continúa a la vez, lo que podría ahogar tu proceso y realmente ralentizarlo.

Answer 2

Cada vez que tiene un proceso de larga ejecución, normalmente puede obtener un rendimiento adicional en los sistemas multiprocesador haciendo diferentes subprocesos para cada tarea de entrada. Entonces, diría que es muy probable que va por el camino correcto.

Answer 3

Hubiera pensado que esto dependería de si el proceso está limitado por la CPU o el disco. Si el proceso está limitado por disco, pensé que podría ser una mala idea lanzar demasiados hilos, ya que las diferentes extracciones podrían competir entre sí.

Esto se siente como algo que podría necesitar medir para obtener la respuesta correcta para lo mejor.

Answer 4

Tengo que estar en desacuerdo con ciertas declaraciones aquí chicos.

Antes que nada, no veo ninguna diferencia entre ThreadPool y Tareas en coordinación o control. Especialmente cuando las tareas se ejecutan en ThreadPool y tiene fácil control sobre las tareas, las excepciones se propagan agradablemente a la persona que llama mientras espera o espera en las tareas. Cuando todas (tareas) etc.

En segundo lugar, la E/S no tiene que ser el único cuello de botella aquí, dependiendo de los datos y del nivel de compresión, el ZIPping tomará probablemente más tiempo que leer el archivo del disco.

Se puede pensar de muchas maneras, pero lo mejor sería algo como la cantidad de núcleos de CPU o un poco menos.

Cargando rutas de archivos a ConcurrentQueue y luego permitiendo que las tareas en ejecución dequenue filepaths, carguen archivos, los copien, los guarde.

Desde allí puede modificar el número de núcleos y jugar con equilibrio de carga.

No sé si postal admite la partición de archivos durante la compresión, pero en algunos casos avanzados/compleja que podría ser una buena idea, especialmente en archivos grandes ...

WOW, que es de 6 años de edad pregunta, Bummer! No me he dado cuenta ... :)