TPL Dataflow против простого семафора

В процессе в основном выполняются операции ввода-вывода с некоторыми второстепенными операциями ЦП (в основном десериализация строк).

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

Итак, вам нужно сосредоточиться на параллельной асинхронности.

• SemaphoreSlim - это стандартный шаблон для этого, как вы обнаружили.
• TPL Dataflow также может выполнять параллелизм (как в асинхронной, так и в параллельной формах).

ForEachAsync может принимать несколько форм; обратите внимание, что в сообщении блога , на которые вы ссылались, существует 5 различных реализаций этого метода, каждая из которых допустима. «[T] здесь существует множество различных семантик, возможных для итерации, и каждая из них приведет к разным вариантам дизайна и реализации». Для ваших целей (не требующих распараллеливания ЦП) вам не следует рассматривать те, которые используют Task.Run или разбиение на разделы. В мире асинхронного параллелизма любая реализация ForEachAsync будет просто синтаксическим сахаром, скрывающим, какую семантику она реализует, поэтому я стараюсь ее избегать.

Остается SemaphoreSlim против ActionBlock. Обычно я рекомендую людям начинать с SemaphoreSlim и подумать о переходе на TPL Dataflow, если их потребности станут более сложными (таким образом, что кажется, что они выиграют от конвейера потока данных).

Например, «Частью требования является возможность настройки степени параллелизма».

Вы можете начать с разрешения некоторой степени параллелизма - когда то, что регулируется, представляет собой единую целую операцию (выборка данных из URL-адреса, десериализация загруженных данных в объекты, сохранение в динамике crm и в другой базе данных и обновление первой базы данных). Вот где SemaphoreSlim было бы идеальным решением.

Но вы можете решить, что хотите иметь несколько регуляторов: скажем, одну степень параллелизма для количества загружаемых URL-адресов, отдельную степень параллелизма для сохранения и отдельную степень параллелизма для обновления исходной базы данных. И тогда вам также нужно будет ограничить «очереди» между этими точками: только определенное количество десериализованных объектов в памяти и т. Д. - чтобы быстрые URL-адреса с медленными базами данных не вызывали проблем с вашим приложением, использующим слишком много объем памяти. Если это полезная семантика, значит, вы начали подходить к проблеме с точки зрения потока данных, и именно поэтому вам может быть лучше подойдет такая библиотека, как TPL Dataflow.

Вот преимущества подхода семафор:

1. Простота

И вот преимущества подхода TPL Dataflow:

1. Параллелизм задач поверх параллелизма данных
2. Оптимальное использование ресурсов (пропускная способность, ЦП, подключения к базе данных)
3. Настраиваемая степень параллелизма для каждой разнородной операции
4. Уменьшение объема памяти

Рассмотрим, например, следующую реализацию семафора:

string[] urls = FetchUrlsFromDB();
var cts = new CancellationTokenSource();
var semaphore = new SemaphoreSlim(10); // Degree of parallelism (DOP)
Task[] tasks = urls.Select(url => Task.Run(async () =>
{
    await semaphore.WaitAsync(cts.Token);
    try
    {
        string rawData = DownloadData(url);
        var data = Deserialize(rawData);
        PersistToCRM(data);
        MarkAsCompleted(url);
    }
    finally
    {
        semaphore.Release();
    }
})).ToArray();
Task.WaitAll(tasks);

Вышеупомянутая реализация гарантирует, что в любой момент одновременно будет обрабатываться не более 10 URL-адресов. Однако координации между этими параллельными рабочими процессами не будет. Так, например, вполне возможно, что в данный момент все 10 параллельных рабочих процессов будут загружать данные, в другой момент все 10 будут десериализовать необработанные данные, а в другой момент все 10 будут сохранять данные в CRM. Это далеко не идеально. В идеале вы хотели бы, чтобы узкое место всей операции, будь то сетевой адаптер, ЦП или сервер базы данных, работало все время без остановки и не использовалось недостаточно (или полностью не использовалось) в различные случайные моменты.

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

Если количество URL-адресов очень велико, скажем, 1000000, то подход с использованием семафоров, описанный выше, также вызывает серьезные проблемы использования памяти. URL-адрес может иметь размер в среднем 50 байт, а Task, подключенный к CancellationToken, может быть в 10 раз тяжелее или больше. Конечно, вы можете изменить реализацию и использовать _4 _ более умным способом, который не создает так много задач, но это будет противоречить основному (и единственному) аргументу этого подхода - его простоте.

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