Використання 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 має на увазі, що ви все-таки доходите до межі своїх ресурсів, у такому випадку ви не слід намагатися запустити власні теми?

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

Інші відповіді тут, здається, не залишають найважливішого моменту:

Якщо ви не намагаєтеся паралелізувати операційну процесору оперативну роботу, щоб зробити її швидше на сайті з низьким навантаженням, немає сенсу використовувати робочу нитку взагалі.

Це стосується як вільних потоків, створених new Thread(...), так і робочих потоків у ThreadPoolвідповіді на QueueUserWorkItemзапити.

Так, це правда, ви можете поголодувати ThreadPoolпроцесом ASP.NET, поставивши в чергу занадто багато елементів роботи. Це не дозволить ASP.NET обробляти подальші запити. Інформація у статті в цьому відношенні є точною; той самий пул потоків, який використовується QueueUserWorkItem, також використовується для обслуговування запитів.

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

Більшу частину часу я бачу або чую про те, що багатопотоковий код неправильно використовується в ASP.NET, це не для чергової роботи з процесором. Він призначений для черги роботи, пов'язаної з входом / виводом. І якщо ви хочете виконувати роботу вводу / виводу, тоді вам слід використовувати потік вводу / виводу (порт завершення вводу / виводу).

Зокрема, ви повинні використовувати зворотні дзвінки async, підтримувані будь-яким класом бібліотеки, який ви використовуєте. Ці методи завжди дуже чітко марковані; вони починаються зі слів Beginі End. Як і в Stream.BeginRead, Socket.BeginConnect, WebRequest.BeginGetResponse, і так далі.

Ці методи роблять використовувати ThreadPool, але вони використовують IOCPs, у яких НЕ втручаються запитів 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).

Зі статті :

Q) Якщо мій додаток ASP.NET використовує потоки CLR ThreadPool, чи не голодуватиму ASP.NET, який також використовує CLR ThreadPool для виконання запитів? ..

A) Підводячи підсумок, не хвилюйтесь про голодування ASP.NET ниток, і якщо ви думаєте, що тут є проблема, повідомте мене про це, і ми подбаємо про це.

Q) Чи повинен я створити власні теми (нова тема)? Чи не буде це краще для ASP.NET, оскільки він використовує CLR ThreadPool.

А) Будь ласка, не варто. Або по-іншому, ні !!! Якщо ви справді розумні - набагато розумніші за мене, - ви можете створити власні теми; інакше навіть не думай про це. Ось кілька причин, чому не слід часто створювати нові теми:

1. Це дуже дорого, порівняно з QueueUserWorkItem ... До речі, якщо ви можете написати кращий ThreadPool, ніж 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. Є різниця, і відмінність важлива.

Нитки проти обробки

І потоки, і процеси - це методи паралелізації додатків. Однак процеси є незалежними блоками виконання, які містять власну інформацію про стан, використовують власні адресні простори та взаємодіють один з одним за допомогою міжпроцесорних механізмів зв'язку (як правило, керованих операційною системою). Програми, як правило, поділяються на процеси на етапі проектування, а головний процес явно породжує підпроцеси, коли є сенс логічно розділяти значну функціональність додатків. Процеси, іншими словами - архітектурна конструкція.

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

Джерело

Я не згоден із посиланням на цю статтю (C # feeds.com). Створити нову нитку легко, але небезпечно. Оптимальна кількість активних потоків для запуску на одному ядрі насправді напрочуд мала - менше 10. Не надто просто змусити машину витрачати час на перемикання потоку часу, якщо нитки створені для другорядних завдань. Нитки - це ресурс, який ЗАПОВІДЬ управління. Абстракція WorkItem є для вирішення цього питання.

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

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

Незалежно від того, використовує чи не IIS той самий ThreadPool для обробки вхідних запитів, важко отримати остаточну відповідь, а також, схоже, змінився за версіями. Тож здавалося б гарною ідеєю не використовувати нитки ThreadPool надмірно, щоб у IIS було доступно багато їх. З іншого боку, нерестування власної нитки для кожного маленького завдання здається поганою ідеєю. Імовірно, у вас є якесь замикання вашої реєстрації, тому лише один потік може просуватися за один раз, а решта буде просто по черзі плановим і позаплановим (не кажучи вже про накладення нересту нової нитки). По суті, ви стикаєтеся з точними проблемами, які ThreadPool покликаний уникати.

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

Ви можете використовувати 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);
                  }
                });