ThreadPools против собственных потоков для длительных процессов

Question

У нас есть несколько длительных бизнес-процессов, которые инициируются через службы WCF, работающие в IIS (интегрированный режим) на WS 2008 R2.Эти бизнес-процессы обычно включают в себя много взаимодействия с нашим сервером SQL Server.Мы создали специальную реализацию очереди задач, в которой запросы помещаются в очередь посредством первоначального вызова службы, а затем выполняются на основе приоритета.Это выполнение может занять много времени (20-30 минут).Затем клиенты могут запросить сервер о ходе выполнения своих собственных фоновых задач.

В нашей текущей реализации задачи запускаются в отдельном потоке для выполнения, а не из ThreadPool.Это было сделано из-за чтения рекомендаций о том, что не выполняются долго выполняющиеся задачи с использованием ThreadPool, чтобы предотвратить голодание запросов ASP.NET.Мы контролируем количество порождаемых потоков, устанавливая верхний предел на количество фоновых задач, которые могут выполняться одновременно.Таким образом, мы пытаемся контролировать нагрузку на процессор и предотвращать слишком большое переключение контекста потока.Хотя все это происходит, нам, конечно, все еще нужно обслуживать обычные «онлайновые» запросы на приложение.

После прочтения этого поста Томасом Марквардтом я обеспокоено том, что мы не используем ThreadPool, поскольку мы не получим преимущества встроенной в него эвристики настройки.Мы уже решаем проблему завершения работы, о которой Томас упоминает, подключившись к событию ApplicationEnd и отменив долго выполняющиеся задачи.Итак, мой вопрос, должны ли мы перейти на использование ThreadPool?Как насчет того, чтобы эти нити были связаны в течение длительных периодов времени?Если я правильно понимаю Томаса, он говорит, что это не имеет значения, так как ThreadPool настроится на создание большего количества запросов для обслуживания обычных онлайн-операций?Я также прочитал этот вопрос StackOverflow , который охватывает те же вопросы, но я все еще не уверен относительно дальнейших действий.

Answer 1

Мое предложение состоит в том, чтобы избежать ThreadPool, поскольку у меня возникают именно проблемы с нехваткой потоков, предложенные по указанным вами ссылкам.

Наш продукт позволяет пользователю отключить вызов веб-службы, которая выполняет серию цитат. Это может быть длительный процесс продолжительностью до 40 минут, процесс цитирования требует интенсивной загрузки ЦП, поэтому мы используем пул потоков на нашем четырехъядерном сервере для получения максимальной загрузки ЦП.

Однако, поскольку ASP.NET выглядит так, как будто он использует пул потоков для обслуживания запросов, у нас возникает проблема, из-за которой любые новые задания, отправляемые пользователями, никогда не начинаются до тех пор, пока не завершится первая работа из-за отсутствия доступных потоков в пуле , Чтобы обойти это, я использовал класс, который я нашел в сети некоторое время назад под названием ThreadPoolThrottle. Это немного облегчило проблемы, но с ростом использования системы мы сталкиваемся с теми же проблемами.

Сейчас я рассматриваю предложение VinayC о запуске кавычек вне процесса, чтобы предотвратить голодание потоков в моем приложении asp.net.

Answer 2

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