Фоновые задачи и периодические задания в ASP.NET и новый API QueueBackground­WorkItem в .NET 4.5.2. Часть первая, общее представление о потоках в ASP.NET.

Много всего у меня накопилось за последние годы по поводу вышеуказанной темы, поэтому решил написать данный цикл статей. Чтобы систематизировать полученную информацию и сделать простой и доступной её для других. Ведь рано или поздно почти любой разработчик ASP.NET столкнётся с подобными задачами. И надеюсь, что информация собранная здесь и далее, окажется полезной в подобной ситуации. Цель данного цикла: первое – описать процесс обработки запросов в ASP.NET с точки зрения использования потоков Windows, второе – привести пошаговые инсрукции использования инструментов для более глубокого погружения в тему и третье – привести методы решения некоторых распростронённых задач (фоновые задачи и периодические задания в ASP.NET). При этом постараюсь сделать материал простым и доступным для понимания. Но также по мере продвижения вперёд будет более глубокое погружение втему. И так, начну с общего описания деталей хостинга приложений ASP.NET в IIS, то есть с описания истоков, для последующего лучшего понимания природы возникновения этих самых задач. Как известно, каждое приложение ASP.NET выполняется в отдельном домене приложения (Application domain). В свою очередь несколько доменов приложений (разных приложений ASP.NET) объединяются в пул приложений IIS, который представляет из себя рабочий процесс Windows под названием W3WP.EXE. Пул IIS может содержать как одно так и множество приложений. Ну и пулов приложений тоже может быть много. На нижнем рисунке поакзана схема, которая была вырезана отсюда.



Открыв диспетчер IIS можно увидеть список пулов приложений на машине, как показано ниже.



Как уже отметил выше, конвейер обработки запросов IIS и ASP.NET был описан тут. Здесь же, будет приведена и описана схема илюстрирующая работу конвейера с точки зрения использования потоков. Ниже вы можете увидеть её.


Когда запрос приходит на веб-сервер первым местом куда он попадает является драйвер режима ядра HTTP.SYS, далее он передаётся IIS. Этот процесс наглядно проиллюстрирован выше. Коммуникация между HTTP.SYS и IIS осуществляется с помощью портов завершения ввода-вывода (I/O Completion Port). В IIS есть своя очередь запросов для пула



и свой пул потоков, который обслуживает запросы без участия ASP.NET. К таковым относятся например запросы к статическому контенту. Если же запрос предназначен для ASP.NET, то в игру вступает CLR со своим пулом потоков. Тут важно отметить, что на весь пул приложения, то есть на процесс W3WP.EXE имеется один пул потоков CLR, при условии, что в процесс загружена только одна версия CLR. Получается, что для всех доменов приложений (Application domains), по сути разных приложений, используется общий набор потоков. Чтобы подкрепить теорию практикой нужно создать приложени. Поскольку тема статьи относится к новой версии .NET Framework нужно скачать и установить её. Сначала нужно установить Microsoft .NET Framework 4.5.2, а затем Microsoft .NET Framework 4.5.2 Developer Pack. Ну и конечно иметь у себя Visual Studio. Создаём пустой проект ASP.NET в Visual Studio.



Затем запускаем его с использованием локального сервера IIS открываем процесс в Process Explorer.



Теперь нам нужно исследовать этот процесс Windows. Для этого нам понадобится отладчик WinDbg из Windows Software Development Kit. Загружаем установщик



выбираем загрузить только WinDbg если остальное у вас уже установлено на машине.



Устанавливаем обе версии (X86 и X64).



Затем скачиваем расширение Psscor4 для отладчика



и устанавливаем его.



Запускаем отладчик WinDbg и устанавливаем источник (srv*d:\debug\symbols*http://msdl.microsoft.com/download/symbols) символов отладки.



Запускаем приложение и подключаем к нему отладчик.



При этом набрав инструкцию загрузки расширения Psscor4

.load D:\Tools\Psscor4\Psscor4\x86\x86\psscor4.dll

Выводим информацию о пуле потоков введя команду: !ThreadPool.



Продолжение следует...
Андрей
25.02.2015 10:58
Заинтриговал.. будет ли продолжение?
25.02.2015 12:54
Будет, вот только когда...пока времени нет.