Task.Factory.StartNew или Parallel.ForEach для многих длительных задач?

Возможно, вы этого не знаете, но члены класса Parallel — это просто (сложные) оболочки вокруг объектов Task. Если вам интересно, класс Parallel создает объекты Task с помощью TaskCreationOptions.None. Однако MaxDegreeOfParallelism повлияет на эти объекты задачи, независимо от того, какие параметры создания будут переданы конструктору объекта задачи.

TaskCreationOptions.LongRunning дает «подсказку» базовому TaskScheduler, что он может работать лучше с превышением количества потоков. Переподписка хороша для потоков с высокой задержкой, например, ввода-вывода, потому что она назначит более одного потока (да, потока, а не задачи) одному ядру, так что ему всегда будет чем заняться, вместо того, чтобы ждать операция для завершения, пока поток находится в состоянии ожидания. На TaskScheduler, который использует ThreadPool, он будет запускать задачи LongRunning в своем собственном выделенном потоке (единственный случай, когда у вас есть поток для каждой задачи), в противном случае он будет работать нормально, с планированием и перехватом работы ( собственно, чего вы тут хотите)

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

Вам может понадобиться Parallel.ForEach. Однако добавление MaxDegreeOfParallelism, равного такому большому числу, на самом деле не гарантирует, что одновременно будет выполняться такое количество потоков, поскольку задачи по-прежнему будут контролироваться ThreadPoolTaskScheduler. Этот планировщик будет уменьшать количество потоков, работающих одновременно, до минимально возможного количества, что, я полагаю, является самой большой разницей между двумя методами. Вы можете написать (и указать) свой собственный TaskScheduler, который будет имитировать максимальную степень поведения параллелизма и иметь лучшее из обоих миров, но я сомневаюсь, что вы заинтересованы в этом.

Я предполагаю, что в зависимости от задержки и количества фактических запросов, которые вам нужно выполнить, использование задач будет работать лучше во многих (?) Случаях, хотя в итоге потребуется больше памяти, в то время как параллельное использование ресурсов будет более последовательным. Конечно, асинхронный ввод-вывод будет работать чудовищно лучше, чем любой из этих двух вариантов, но я понимаю, что вы не можете этого сделать, потому что используете устаревшие библиотеки. Так что, к сожалению, вы застрянете с посредственной производительностью независимо от того, какой из них вы выберете.

Реальным решением было бы найти способ реализовать асинхронный ввод-вывод; так как я не знаю ситуацию, я не думаю, что могу быть более полезным, чем это. Ваша программа (чтение, поток) продолжит выполнение, а ядро ​​будет ждать завершения операции ввода-вывода (это также известно как использование портов завершения ввода-вывода). Поскольку поток не находится в состоянии ожидания, среда выполнения может выполнять больше работы с меньшим количеством потоков, что обычно приводит к оптимальному соотношению между количеством ядер и количеством потоков. Добавление большего количества потоков, как бы мне этого ни хотелось, не означает повышения производительности (на самом деле, это часто может повредить производительности из-за таких вещей, как переключение контекста).

Однако весь этот ответ бесполезен для определения окончательного ответа на ваш вопрос, хотя я надеюсь, что он даст вам необходимое направление. Вы не узнаете, что работает лучше, пока не профилируете это. Если вы не попробуете их оба (я должен уточнить, что я имею в виду задачу без опции LongRunning, позволяющую планировщику обрабатывать переключение потоков) и не профилировать их, чтобы определить, что лучше всего подходит для вашего конкретного варианта использования, ты недооцениваешь себя.

Оба варианта совершенно не подходят для вашего сценария.

TaskCreationOptions.LongRunning, безусловно, лучший выбор для задач, не связанных с ЦП, поскольку TPL (Parallel классы/расширения) почти исключительно предназначены для максимизации пропускной способности операции, связанной с ЦП, за счет ее выполнения на нескольких ядрах (а не потоках).

Однако 1000 задач — неприемлемое число для этого. Независимо от того, работают ли они все одновременно, это не совсем проблема; даже 100 потоков, ожидающих синхронного ввода-вывода, — неприемлемая ситуация. Как предполагает один из комментариев, ваше приложение будет использовать огромное количество памяти и в конечном итоге будет тратить почти все свое время на переключение контекста. TPL не предназначен для этого масштаба.

Если ваши операции связаны с вводом-выводом, а если вы используете веб-сервисы, то так и есть, тогда асинхронный ввод-вывод — это не только правильное решение, но и единственное решение. . Если вам нужно изменить архитектуру вашего кода (например, добавить асинхронные методы к основным интерфейсам, которых изначально не было), сделайте это, потому что порты завершения ввода-вывода — это < em>единственный механизм в Windows или .NET, который может должным образом поддерживать этот конкретный тип параллелизма.

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

Хотя это не прямое сравнение, я думаю, оно может вам помочь. Я делаю что-то похожее на то, что вы описываете (в моем случае я знаю, что на другом конце есть кластер серверов с балансировкой нагрузки, обслуживающий вызовы REST). Я получаю хорошие результаты, используя Parrallel.ForEach для запуска оптимального количества рабочих потоков, при условии, что я также использую следующий код, чтобы сообщить своей операционной системе, что она может подключаться к большему количеству конечных точек, чем обычно.

    var servicePointManager = System.Net.ServicePointManager.FindServicePoint(Uri);
    servicePointManager.ConnectionLimit = 250;

Обратите внимание, что вы должны вызывать это один раз для каждого уникального URL-адреса, к которому вы подключаетесь.