Улучшение производительности в цепи "чтение с диска - обработка - запись в БД"

Question

Задача. Считать файлы с папки, для каждого произвести некоторые действия, и результат для каждого файла записать в базу данных, которая, будем считать, находится на другом компьютере. Необходимо увеличить производительность алгоритма с помощью распараллеливания задачи между ядрами процессора. Также стоит отметить, что при работе алгоритма происходит вызов стороннего приложения и считывание результата, через коды возврата. Но это не единственное действие, выполняемое для получения результата.

---

Ход моих мыслей таков. Задача разбивается на три операции:

1. чтение файла
2. получение результата из прочитанного
3. запись результата в БД

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

Значит, заведу две очереди Producer-Consumer:

1. производитель --- поток, выполняющий операцию чтения файлов из папки. Потребители --- потоки, получающие результат из прочитанного
2. производители --- потоки, получающие результат из прочитанного. Потребитель --- поток, записывающий результат в БД

---

Первый вопрос, касается числа потоков-потребителей для первой очереди. В похожем вопросе Как лучше распараллелить задачу? было рекомендовано выставлять число потоков выполняющих основную работу равным количеству ядер процессора. Но не следует ли уменьшить это число, дабы "освободить" одно ядро для потоков первой и третьей операции?

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

Answer 1

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

Стратегий для такого бенчмарка есть несколько.

1. Проводить бенчмарк при первом, или каждом, запуске, фиксируя оптимальное количества потоков. Здесь можно сберечь время если сохранять оптимальное значение для известных характеристик железа - объёма памяти и процессора - пересчитывая оптимум только если железо поменялось.

2. Если эксклюзивное использование железа не подразумевается, а значит доступные вычислительные ресурсы не являются константой, то оптимальней будет динамически определять оптимальное число потоков для всех процедур. Примерный алгоритм: запускаем один процесс, записываем время выполнения. Запускаем второй - записываем время. Смотрим разницу - не увеличилось? Запускаем ещё один процесс. Снова смотрим время. Запускаем ещё. Измеряем снова. Увеличилось? Стоп, лишний процесс убираем. Через некоторое время снова пытаемся запустить один дополнительный процесс.

Понятно что стратегии можно и нужно комбинировать. Например, если вы точно знаете что на 16 Гб памяти больше чем 8 процессов не имеет смысла запускать, то в динамическом алгоритме на 8 процессах стоит остановиться.

Answer 2

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

void Main()
{
    var files = Enumerable.Range(0, 100).Select(x => 
    {
        var fname = $"{x}.txt";
        Console.WriteLine($"Reading {fname}");
        return fname;
    });             

    WriteToDb(files.AsParallel().Select(x=>Process(x)));

    // Если хочется начать писать в БД до того, как все файлы будут обработаны. Я бы выбрал этот вариант
    //WriteToDb(files.AsParallel().WithMergeOptions(ParallelMergeOptions.NotBuffered).Select(x=>Process(x)));

    // Если уж сильно хочется контролить количество потоков. Не советую этого делать, лучше побеспокойтесь о памяти.
    // WriteToDb(files.AsParallel().WithDegreeOfParallelism(Environment.ProcessorCount).Select(x=>Process(x)));             
}   

string Process(string fname)
{
    Console.WriteLine($"processing {fname}");

    for (var i = 0; i < 1000000000; i++)
    {       
    }   

    return $"{fname} processed";
}

void WriteToDb(IEnumerable<string> results)
{
    Console.WriteLine("Start writing to DB");
    foreach (var result in results)
    {
        Console.WriteLine($"Saving {result}");
    }
}

Обратите внимание на загрузку процессоров, я уверен, что она поползет вверх до 100% всеми процессорами/ядрами. Это не только проще, чем синхронизировать все вручную, это ещё (в теории) должно быть эффективней ручного создания кучи потоков, так как стандарнтый шедулер может переиспользовать уже созданные потоки в пуле.

UPD. Дополню, что происходит.

WriteToDb(files.AsParallel().Select(x=>Process(x)));

Процесс такой: читаем параллельно несколько файлов, обрабатываем параллельно, складываем результат. Когда все результаты по всем файлам готовы (или не все - решает PLINQ) - пишем в БД. Количество параллельно работающих потоков определяет шедулер.

// Если хочется начать писать в БД до того, как все файлы будут обработаны. Я бы выбрал этот вариант
//WriteToDb(files.AsParallel().WithMergeOptions(ParallelMergeOptions.NotBuffered).Select(x=>Process(x)));

Процесс такой: читаем параллельно несколько файлов, обрабатываем параллельно, результаты параллельно пишем в БД. Количество параллельно работающих потоков определяет шедулер.

// Если уж сильно хочется контролить количество потоков. Не советую этого делать, лучше побеспокойтесь о памяти.
// WriteToDb(files.AsParallel().WithDegreeOfParallelism(Environment.ProcessorCount).Select(x=>Process(x))); 

Процесс такой: читаем параллельно несколько файлов, обрабатываем параллельно, складываем результат. Когда все результаты по всем файлам готовы (или не все - решает PLINQ) - пишем в БД. Количество параллельно работающих заданы тут WithDegreeOfParallelism.

Также эти варианты можно комбинировать.