Задачи C# TPL - Сколько за один раз

Question

Я изучаю, как использовать TPL для parellizing приложения, которое у меня есть. Приложение обрабатывает ZIP-файлы, выделяя все файлы, хранящиеся в них, и импортирует содержимое в базу данных. Может быть несколько тысяч zip-файлов, ожидающих обработки в данный момент времени.

Как я могу начать отдельную задачу для каждого из этих ZIP-файлов или это неэффективный способ использования TPL?

Спасибо.

Answer 1

Это похоже на проблему, которая лучше подходит для рабочих потоков (отдельный поток для каждого файла), управляемых с помощью ThreadPool, а не TPL. TPL отлично работает, когда вы можете разделить и покорить один элемент данных, но ваши zip-файлы обрабатываются индивидуально.

Диск I/O будет вашей бутылочной горловиной, поэтому я думаю, что вам нужно будет дросселировать количество заданий, выполняемых одновременно. Просто управлять этим с помощью рабочих потоков, но я не уверен, какой контроль у вас есть (если нет) по сравнению с параллелью для foreach, насколько параллелизм продолжается сразу, что может заглушить ваш процесс и фактически замедлить его.

Answer 2

В любое время, когда у вас есть длительный процесс, вы можете получить дополнительную производительность на многопроцессорных системах, создавая разные потоки для каждой задачи ввода. Поэтому я бы сказал, что вы, скорее всего, идите по правильному пути.

Answer 3

Я бы подумал, что это будет зависеть от того, будет ли процесс ограничен процессором или диском. Если процесс ограничен диском, я думал, что может быть плохой идеей начать слишком много потоков, поскольку различные экстракции могут просто конкурировать друг с другом.

Это похоже на то, что вам может понадобиться для измерения, чтобы получить правильный ответ для лучшего.

Answer 4

Я должен не согласиться с некоторыми утверждениями здесь, ребята.

Прежде всего, я не вижу разницы между ThreadPool и задачами в координации или управлении. Особенно, когда задачи выполняются на ThreadPool, и у вас есть легкий контроль над задачами, исключения хорошо передаются вызывающему абоненту во время ожидания или ожидания по Tasks.WhenAll (задачи) и т. Д.

Во-вторых, I/O не должно быть единственным узким местом здесь, в зависимости от данных и уровня сжатия, ZIPпинг будет принимать msot, вероятно, больше времени, чем чтение файла с диска.

Это можно рассматривать по-разному, но я бы лучше пошел на что-то вроде количества ядер процессора или немного меньше.

Загрузка путей к файлам ConcurrentQueue, а затем запуск запущенных задач для удаления файлов, загрузки файлов, их замены и сохранения.

Оттуда вы можете настроить количество ядер и играть с балансировкой нагрузки.

Я не знаю, если ZIP поддерживает файл секционирования при сжатии, но в некоторых передовых/сложных случаях это может быть хорошей идеей, особенно на больших файлах ...

WOW, это 6 лет вопрос, облом! Я не заметил ... :)