У меня всегда было впечатление, что использование ThreadPool для (пусть и некритических) недолговечных фоновых задач считалось лучшей практикой даже в ASP.NET, но затем я наткнулся на в этой статье, которая, как представляется, предполагает иное: аргумент заключается в том, что вы должны оставить ThreadPool для обработки связанных с ASP.NET запросов.
Итак, вот как я делал небольшие асинхронные задачи:
ThreadPool.QueueUserWorkItem(s => PostLog(logEvent))
И статья предлагает вместо этого создать поток явно, похожий на:
new Thread(() => PostLog(logEvent)){ IsBackground = true }.Start()
Первый метод имеет то преимущество, что он управляется и ограничен, но есть потенциал (если статья верна), что фоновые задачи затем соперничают за потоки с обработчиками запросов ASP.NET. Второй метод освобождает ThreadPool, но за счет неограниченного доступа и, следовательно, потенциального использования слишком большого количества ресурсов.
Итак, мой вопрос в том, правильно ли указан совет в статье?
Если ваш сайт получал так много трафика, что ваш ThreadPool был заполнен, то лучше ли выходить из диапазона, или полный поток ThreadPool подразумевает, что вы все равно получаете доступ к своим ресурсам, в каком случае вы не должны пытаться запускать свои собственные потоки?
Уточнение: я просто спрашиваю в рамках небольших некритических асинхронных задач (например, удаленное ведение журнала), не дорогостоящих рабочих элементов, для которых потребуется отдельный процесс (в этих случаях я согласен, что вам понадобится более надежный раствора).
