C# TPL Tâches - Combien en même temps

Question

J'apprends comment utiliser le TPL pour parelliser une application que j'ai. L'application traite les fichiers ZIP, en extrayant tous les fichiers qu'ils contiennent et en important le contenu dans une base de données. Il peut y avoir plusieurs milliers de fichiers zip en attente de traitement à un instant donné.

Ai-je raison de lancer une tâche séparée pour chacun de ces fichiers ZIP ou est-ce une manière inefficace d'utiliser le TPL?

Merci.

Answer 1

Cela semble être un problème mieux adapté aux threads de travail (thread séparé pour chaque fichier) géré avec le ThreadPool plutôt qu'avec le TPL. TPL est génial lorsque vous pouvez diviser et conquérir sur un seul élément de données, mais vos fichiers zip sont traités individuellement. Les E/S de disque vont être votre cou de bouteille, donc je pense que vous aurez besoin d'étrangler le nombre de tâches en cours simultanément. C'est simple à gérer avec des threads de travail, mais je ne suis pas sûr du contrôle que vous avez (si non) sur le parallélisme, pour autant que le parallélisme continue, ce qui pourrait étouffer votre processus et le ralentir.

Answer 2

Chaque fois que vous avez un long processus en cours, vous pouvez généralement obtenir des performances supplémentaires sur les systèmes multiprocesseurs en créant des threads différents pour chaque tâche d'entrée. Donc, je dirais que vous êtes probablement sur la bonne voie.

Answer 3

J'aurais pensé que cela dépendrait si le processus est limité par CPU ou disque. Si le processus est limité par le disque, je pensais que ce serait une mauvaise idée de lancer trop de threads puisque les différentes extractions pourraient juste se faire concurrence. Cela ressemble à quelque chose que vous pourriez avoir besoin de mesurer pour obtenir la bonne réponse pour ce qui est le meilleur.

Answer 4

Je suis en désaccord avec certaines déclarations ici les gars. Tout d'abord, je ne vois aucune différence entre ThreadPool et Tasks dans la coordination ou le contrôle. Surtout lorsque les tâches s'exécutent sur ThreadPool et que vous avez un contrôle facile sur les tâches, les exceptions sont bien propagées à l'appelant pendant l'attente ou l'attente des tâches. Lorsque toutes les tâches sont

Deuxièmement, les E/S ne doivent pas être le seul goulot d'étranglement ici, en fonction des données et du niveau de compression, le ZIPping prendra probablement plus de temps que de lire le fichier sur le disque.

On peut penser à de nombreuses façons, mais je ferais mieux de faire quelque chose comme le nombre de cœurs de processeur ou un peu moins.

Chargement des chemins de fichiers vers ConcurrentQueue, puis autorisation d'exécution des tâches pour déquiler les chemins de fichiers, charger les fichiers, les compresser et les enregistrer. De là, vous pouvez modifier le nombre de cœurs et jouer avec l'équilibrage de charge.

Je ne sais pas si le partitionnement prend en charge les ZIP de fichiers lors de la compression, mais dans certains cas avancés/complexe il pourrait être une bonne idée, surtout sur de gros fichiers ...

WOW, il est de 6 ans question, Bummer! Je n'ai pas remarqué ... :)