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

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

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

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

А такжестатья вместо этого предлагает явно создать поток, похожий на:

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

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

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

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

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