Использование ThreadPool.QueueUserWorkItem в ASP.NET в сценарии с высоким трафиком

Question

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

Итак, вот как я выполнял небольшие асинхронные задачи:

ThreadPool.QueueUserWorkItem(s => PostLog(logEvent))

И статья предлагает вместо этого явно создать поток, аналогично:

new Thread(() => PostLog(logEvent)){ IsBackground = true }.Start()

Преимущество первого метода в том, что он управляемый и ограниченный, но есть вероятность (если статья верна), что фоновые задачи затем соперничают за потоки с обработчиками запросов ASP.NET. Второй метод освобождает ThreadPool, но за счет того, что он неограничен и, следовательно, потенциально использует слишком много ресурсов.

Итак, мой вопрос: правильный ли совет в статье?

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

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

Answer 1

Я не согласен с указанной статьей (C # feeds.com). Создать новую тему легко, но опасно. Оптимальное количество активных потоков для запуска на одном ядре на самом деле удивительно мало - меньше 10. Слишком легко заставить машину тратить время на переключение потоков, если потоки создаются для незначительных задач. Потоки - это ресурс, который требует управления. Для этого есть абстракция WorkItem.

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

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