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

Другие ответы здесь, похоже, не учитывают самый важный момент:

Если вы не пытаетесь распараллелить операцию, интенсивно использующую процессор, чтобы ускорить ее выполнение на сайте с низкой нагрузкой, нет смысла использовать рабочий поток вообще.

Это касается как бесплатных потоков, созданных new Thread(...), так и рабочих потоков в ThreadPool, которые отвечают на QueueUserWorkItem запросы.

Да, это правда, вы можете лишить ThreadPool процесса ASP.NET, поставив в очередь слишком много рабочих элементов. Это предотвратит обработку дальнейших запросов ASP.NET. Информация в статье верна в этом отношении; тот же пул потоков, который используется для QueueUserWorkItem, также используется для обслуживания запросов.

Но если вы фактически ставите в очередь достаточно рабочих элементов, чтобы вызвать это голодание, тогда вы должны истощить пул потоков! Если вы выполняете буквально сотни операций с интенсивным использованием ЦП одновременно, какой смысл иметь другой рабочий поток для обслуживания запроса ASP.NET, когда машина уже перегружена? Если вы столкнулись с такой ситуацией, вам нужно полностью переделать дизайн!

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

В частности, вы должны использовать асинхронные обратные вызовы, поддерживаемые любым классом библиотеки, который вы используете. Эти методы всегда очень четко обозначены; они начинаются со слов Begin и End. Как в Stream.BeginRead, Socket.BeginConnect, WebRequest.BeginGetResponse и так далее.

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

Просто имейте в виду, что асинхронные делегаты не работают таким образом - они будут использовать рабочий поток, как и ThreadPool.QueueUserWorkItem. Это могут делать только встроенные асинхронные методы классов библиотеки .NET Framework. Вы можете сделать это сами, но это сложно и немного опасно и, вероятно, выходит за рамки этого обсуждения.

На мой взгляд, лучший ответ на этот вопрос - не использовать ThreadPool или фоновый Thread экземпляр в ASP.NET. Это совсем не похоже на запуск потока в приложении Windows Forms, где вы делаете это, чтобы пользовательский интерфейс оставался отзывчивым и не заботился о том, насколько он эффективен. В ASP.NET вас беспокоит пропускная способность, и все эти переключения контекста для всех этих рабочих потоков абсолютно убивают вашу пропускную способность, независимо от того, используете вы ThreadPool или нет.

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

Согласно Томасу Маркуадту из группы ASP.NET в Microsoft, безопасно использовать ASP.NET ThreadPool (QueueUserWorkItem).

Из статьи:

В) Если мое приложение ASP.NET использует потоки CLR ThreadPool, не буду ли я голодать по ASP.NET, которая также использует CLR ThreadPool для выполнения запросов? ..

A) Подводя итог, не беспокойтесь о том, что ASP.NET не хватает потоков, и если вы считаете, что здесь есть проблема, дайте мне знать, и мы позаботимся об этом.

В) Должен ли я создавать свои собственные потоки (новый поток)? Разве это не будет лучше для ASP.NET, поскольку он использует CLR ThreadPool.

А) Пожалуйста, не надо. Или, иначе говоря, нет !!! Если вы действительно умны - намного умнее меня - тогда вы можете создавать свои собственные темы; в противном случае даже не думай об этом. Вот несколько причин, по которым вам не следует часто создавать новые темы:

1. Это очень дорого по сравнению с QueueUserWorkItem ... Кстати, если вы можете написать пул потоков лучше, чем CLR, я рекомендую вам подать заявку на работу в Microsoft, потому что мы определенно ищем таких людей, как вы !.

Веб-сайты не должны порождать темы.

Обычно вы переносите эту функцию в службу Windows, с которой затем общаетесь (я использую MSMQ, чтобы общаться с ними).

-- Редактировать

Я описал здесь реализацию: Фоновая обработка на основе очередей в Веб-приложение ASP.NET MVC

-- Редактировать

Чтобы объяснить, почему это даже лучше, чем просто потоки:

Используя MSMQ, вы можете общаться с другим сервером. Вы можете писать в очередь между машинами, поэтому, если вы по какой-то причине определите, что ваша фоновая задача слишком сильно использует ресурсы главного сервера, вы можете просто перенести ее довольно тривиально.

Это также позволяет вам выполнять пакетную обработку любой задачи, которую вы пытаетесь выполнить (отправлять электронные письма / что-то еще).

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

Кроме того, реализация потоковой передачи скрыта - если вы начинаете порождать свои собственные потоки, вы также должны правильно управлять ими. Я не говорю, что вы не можете этого сделать, но зачем изобретать это колесо?

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

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

В идеале вам не нужно использовать отдельный поток для выполнения операции регистрации - просто позвольте исходному потоку завершить операцию как можно быстрее, и именно здесь MSMQ и отдельный поток / процесс потребителя входят в картину. Я согласен с тем, что это сложнее и требует больше усилий для реализации, но вам действительно нужна надежность - непостоянство общей очереди в памяти быстро изнашивает ее.

Вам следует использовать QueueUserWorkItem и избегать создания новых потоков, как если бы вы избежали чумы. Для наглядного изображения, объясняющего, почему вы не будете морить ASP.NET голодом, поскольку он использует тот же ThreadPool, представьте себе очень опытного жонглера, который двумя руками держит в полете полдюжины кеглей для боулинга, мечей или чего-то еще. Чтобы наглядно понять, почему создание собственных потоков - это плохо, представьте, что происходит в Сиэтле в час пик, когда интенсивно используемые въездные пандусы на шоссе позволяют транспортным средствам немедленно выезжать на поток, а не использовать свет и ограничивать количество въездов до одного каждые несколько секунд. . Наконец, подробное объяснение можно найти по этой ссылке:

http://blogs.msdn.com/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications.aspx

Спасибо, Томас

Эта статья неверна. ASP.NET имеет собственный пул потоков, управляемые рабочие потоки для обслуживания запросов ASP.NET. Этот пул обычно состоит из нескольких сотен потоков и отделен от пула ThreadPool, который несколько меньше процессоров.

Использование ThreadPool в ASP.NET не будет мешать рабочим потокам ASP.NET. Использование ThreadPool - это нормально.

Также было бы приемлемо настроить один поток, который предназначен только для регистрации сообщений и использования шаблона производитель / потребитель для передачи сообщений журнала в этот поток. В этом случае, поскольку поток является долгоживущим, вы должны создать один новый поток для запуска регистрации.

Использование новой цепочки для каждого сообщения определенно излишне.

Другой альтернативой, если вы говорите только о ведении журнала, является использование библиотеки вроде log4net. Он обрабатывает ведение журнала в отдельном потоке и заботится обо всех проблемах контекста, которые могут возникнуть в этом сценарии.

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

На каждый процесс приходится один пул потоков. Пул потоков по умолчанию имеет размер 250 рабочих потоков на доступный процессор и 1000 потоков завершения ввода-вывода. Количество потоков в пуле потоков можно изменить с помощью метода SetMaxThreads. Каждый поток использует размер стека по умолчанию и работает с приоритетом по умолчанию.

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

1. Сделан запрос на какую-то страницу
2. HTML возвращается
3. Html сообщает клиенту, что нужно делать дополнительные запросы (js, css, изображения и т. Д.)
4. Дополнительная информация высылается обратно

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

Сэм также прав в том, что использование пула потоков в CLR не вызовет проблем с пулом потоков в IIS. Однако здесь следует обратить внимание на то, что вы не создаете потоки из процесса, вы создаете новые потоки из потоков пула потоков IIS. Есть разница, и различие важно.

Потоки против процесса

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

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

Источник

Вы можете использовать Parallel.For или Parallel.ForEach и определить предел возможных потоков, которые вы хотите выделить для бесперебойной работы и предотвращения истощения пула.

Однако при работе в фоновом режиме вам нужно будет использовать чистый стиль TPL, указанный ниже, в веб-приложении ASP.Net.

var ts = new CancellationTokenSource();
CancellationToken ct = ts.Token;

ParallelOptions po = new ParallelOptions();
            po.CancellationToken = ts.Token;
            po.MaxDegreeOfParallelism = 6; //limit here

 Task.Factory.StartNew(()=>
                {                        
                  Parallel.ForEach(collectionList, po, (collectionItem) =>
                  {
                     //Code Here PostLog(logEvent);
                  }
                });

Я не согласен с указанной статьей (C # feeds.com). Создать новую ветку легко, но опасно. Оптимальное количество активных потоков для запуска на одном ядре на самом деле удивительно мало - менее 10. Слишком легко заставить машину тратить время на переключение потоков, если потоки создаются для второстепенных задач. Потоки - это ресурс, ТРЕБУЮЩИЙ управления. Абстракция WorkItem предназначена для этого.

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

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

Трудно получить окончательный ответ на вопрос, использует ли IIS один и тот же ThreadPool для обработки входящих запросов, и также, похоже, изменился в версиях. Поэтому было бы неплохо не использовать потоки ThreadPool чрезмерно, чтобы в IIS было их много. С другой стороны, создание собственного потока для каждой небольшой задачи кажется плохой идеей. Предположительно, у вас есть какая-то блокировка в вашем журнале, поэтому только один поток может работать за раз, а остальные будут просто по очереди получать запланированные и внеплановые (не говоря уже о накладных расходах на порождение нового потока). По сути, вы сталкиваетесь с теми же проблемами, для предотвращения которых был разработан ThreadPool.

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