многопоточность с использованием threadPool или new thread() в приложении сервера

Question

Я проделал кучу чтения о динамике и последствиях многопоточности в серверном приложении (голодание пула потоков clr и т. Д.), Но, допустим, ради аргумент У меня есть ТОЧНО 4 асинхронных процесса, которые мне нужно выполнить для запроса моей страницы (asp.net) ... Теперь скажем, что время - это более важный элемент, и мой сайт не должен испытывать большой трафик. В этом случае предпочтительнее создавать 4 потока с использованием подхода new Thread() или ThreadPool.QueueUserWorkItem method?

Мое беспокойство (и моя точка) заключается в том, что с использованием ThreadPool method он может создать пул потоков, который слишком велик, чем я действительно хочу? Когда мне нужны только 4 потока, не могу ли я просто создать их самостоятельно, чтобы сохранить количество выделенного домена приложения, минимальные потоки clr?

Answer 1

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

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

Я бы использовал пул потоков и использовал SetMinThreads, чтобы гарантировать, что потоки запускаются без задержки и что их всегда достаточно.

Answer 2

Я бы определенно пошел на подход ThreadPool. Он разработан именно для такого сценария. Пул потоков будет управлять количеством требуемых потоков, чтобы не перегружать систему. Цитируя MSDN:

пула потоков создает новые рабочие потоки или ввод/вывод завершение нитей по требованию, пока он не достигнет минимума для каждой категории. Когда достигнут минимум , пул потоков может создавать дополнительные потоки в этой категории или дождаться завершения некоторых задач. Начиная с .NET Framework 4 пул потоков создает и уничтожает рабочие потоки , чтобы оптимизировать пропускную способность, которая определяется как количество заданий , которые завершаются за единицу времени. Слишком мало потоков может не сделать оптимальным использованием доступных ресурсов, тогда как слишком много потоков могут увеличить конкуренцию ресурсов.

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

Если у вас есть доступ к .net 4.0, вы можете использовать класс TPL Task (он также использует ThreadPool под капотом), так как он имеет еще более привлекательные функции.