Без этой настройки stop watch внутри каждого вызова показывали приемлемое время в сумме, типа 150-250мс * 10. Но общий stop watch на всю джобу выдавал значительно больше. Будто все висело где-то.
А есть возможность заменить на Task.WhenAll с SemaphoreSlim и посчитать время вызова и общее время исполнения? Очень интересно на сколько улучшится. Так как правильно заметил @CsharponelovePLINQ сделан под CPU-bound задачи, а не под I/O ( внутри джобы обращение к внешней системе). Ещё было бы интересно посмотреть метрики до и после по ThreadPool: количество занятых потоков, доступных потоков и очередь, если она есть.
суть в том, что ConfigureAwait(false) разрешил твоему коду не возвращаться в исходно захваченный контекст/планировщик, а продолжить выполнение на любом доступном потоке из ThreadPool. Эти «лишние» миллисекунды и есть continuation после него. И сейчас то, что общее время всё равно немного не совпадает с суммой внутренних замеров, нормально, так как планирование задач, переключение потоков и накладные расходы параллелизма никуда полностью не исчезают. Не знаю как там устроено у вас, возможно, лучше не мешать это с PLINQ/Parallel, а собрать задачи и выполнить через Task.WhenAll? И при необходимости ограничить параллельность через SemaphoreSlim. Так все должно быть быстрее и время на часах сойдется в итоге. Да и будет, наверное получше.
@Csharponeloveуже дополнил ниже про Hangfire.
А есть возможность заменить на Task.WhenAll с SemaphoreSlim и посчитать время вызова и общее время исполнения? Очень интересно на сколько улучшится. Так как правильно заметил @CsharponelovePLINQ сделан под CPU-bound задачи, а не под I/O ( внутри джобы обращение к внешней системе). Ещё было бы интересно посмотреть метрики до и после по ThreadPool: количество занятых потоков, доступных потоков и очередь, если она есть.
Спасибо за очень интересную статью!
суть в том, что ConfigureAwait(false) разрешил твоему коду не возвращаться в исходно захваченный контекст/планировщик, а продолжить выполнение на любом доступном потоке из ThreadPool. Эти «лишние» миллисекунды и есть continuation после него. И сейчас то, что общее время всё равно немного не совпадает с суммой внутренних замеров, нормально, так как планирование задач, переключение потоков и накладные расходы параллелизма никуда полностью не исчезают. Не знаю как там устроено у вас, возможно, лучше не мешать это с PLINQ/Parallel, а собрать задачи и выполнить через Task.WhenAll? И при необходимости ограничить параллельность через SemaphoreSlim. Так все должно быть быстрее и время на часах сойдется в итоге. Да и будет, наверное получше.