Может ли кто-нибудь объяснить различия в IIS между пулами приложений, рабочими процессами и доменами приложений? Кроме того, как они работают вместе? Я прочитал пару статей, но это все еще немного сбивает с толку.
Ответы:
Я пытаюсь выразить их другими словами.
На сервере может быть много сайтов asp.net, работающих вместе. Каждый сайт - это домен приложения .
Вы должны назначить каждому из них по одному пулу приложений . Многие домены приложений (сайты) могут иметь один и тот же пул приложений, и поскольку они имеют один и тот же пул приложений, они запускаются под одними и теми же процессами и под одной учетной записью - и у них одинаковые настройки пула. Если этот пул перезапускается, то перезапускаются все сайты в этом пуле.
Теперь в каждом пуле может быть один или несколько рабочих процессов . Каждый рабочий процесс - это отдельная программа, которая запускает ваш сайт, имеет свои статические переменные, разные вызовы запуска и остановки и т. Д. Различные рабочие процессы не взаимодействуют друг с другом, и единственный способ обмена данными - из общих файлов или общей базы данных. Если у вас несколько рабочих процессов и один из них выполняет длительные вычисления, то другой может позаботиться об обработке интернет-вызовов и отображении контента.
Когда вы назначаете несколько рабочих процессов одному пулу, вы создаете вызываемый веб-сад, и ваш сайт как бы запускается с нескольких компьютеров, если компьютер является одной обрабатывающей машиной.
Каждый рабочий процесс может иметь много потоков.
Как больше рабочих процессов влияет на вас:
когда у вас есть один рабочий процесс, все проще, в вашем приложении все статические переменные одинаковы, и вы используете их lockдля их синхронизации.
Когда вы назначаете более одного рабочего процесса, вы все равно продолжаете использовать lockдля статических переменных, статические переменные не различаются между многими запусками вашего сайта, и если у вас есть какой-то общий ресурс (например, создание эскиза на диске) тогда вам нужно синхронизировать рабочий процесс с Mutex.
Еще одно замечание. Похоже, что чем больше рабочих процессов, тем более плавная асинхронная загрузка страниц. Есть небольшая проблема с обработчиком сеанса asp.net, который блокирует весь процесс для загрузки страницы - это хорошо и плохо, зависит от того, знаете ли вы и обрабатываете ли это - или измените его.
Так что давайте поговорим об одном сайте только с множеством рабочих процессов. Здесь вы сталкиваетесь с проблемой, с которой вам нужно синхронизировать изменение общего ресурса Mutex. Но страницы / обработчики, использующие сеанс, не являются асинхронными, потому что сеанс их блокирует. Это хорошо для начала, потому что вы избегаете выполнять синхронизацию многих точек самостоятельно.
Некоторые вопросы по этой теме:
веб-приложение заблокировано во время обработки другого веб-приложения при совместном использовании того же сеанса.
JQuery. Ajax-вызовы веб-службы кажутся синхронными.
Сервер ASP.NET не обрабатывает страницы асинхронно.
Полная замена сеанса ASP.Net.
Теперь эта блокировка сеанса не влияет на разные сайты.
Среди разных сайтов более проработанный процесс может помочь одному сайту не блокировать другой долгим процессом.
Также среди разных сайтов больше пулов также может помочь, потому что в каждом пуле есть хотя бы один рабочий процесс, но помните и убедитесь сами, используя проводник процессов, каждый рабочий процесс занимает больше памяти вашего компьютера и один большой сервер с памятью 16 ГБ и на одном сервере SQL не может быть слишком много разных рабочих процессов - например, на сервере с 100 общими сайтами у вас не может быть 100 разных пулов.
Значение для разработчиков ASP.NET: сделать ваш веб-сайт масштабируемым, не используйте внутрипроцессный сеанс и не используйте блокировку статической переменной класса для синхронизации.
Да, хотя не каждое приложение является веб-сайтом. Вы можете иметь приложение, которое вложен под веб - сайта.
Да, каждое приложение должно иметь один рабочий процесс (пул приложений), хотя один пул приложений может обслуживать несколько приложений. Одно веб-приложение может быть распределено (веб-сад / ферма), что означает, что оно будет выполняться в нескольких процессах.
Каждый процесс будет работать в собственном домене приложения (каждый пул приложений - это отдельный домен приложения).
Из MSDN.
Приложение - это группировка контента на корневом уровне веб-сайта или группировка контента в отдельной папке в корневом каталоге веб-сайта.
Пул приложений определяет группу из одного или нескольких рабочих процессов, настроенных с общими параметрами, которые обслуживают запросы к одному или нескольким приложениям, назначенным этому пулу приложений. Поскольку пулы приложений позволяют набору веб-приложений совместно использовать один или несколько аналогичным образом настроенных рабочих процессов, они предоставляют удобный способ изолировать набор веб-приложений от других веб-приложений на сервере. Границы процессов разделяют каждый рабочий процесс; поэтому проблемы приложений в одном пуле приложений не влияют на веб-сайты или приложения в других пулах приложений. Пулы приложений значительно повышают надежность и управляемость вашей веб-инфраструктуры.
Из исходной ссылки: -http: //weblogs.asp.net/owscott/archive/2007/09/02/application-vs-appdomain.aspx
Приложение - это термин IIS, но он используется в ASP.NET. По сути, он создает «песочницу» или набор границ для отделения разных сайтов или частей сайтов от других.
AppDomain - это термин .NET. (В IIS7 домены приложений играют более значительную роль в IIS, но по большей части это термин ASP.NET)
Рабочий процесс используется для обработки запроса веб-приложения.