Я пытаюсь выразить их другими словами.
На сервере может быть много сайтов 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
Рабочий процесс используется для обработки запроса веб-приложения.
источник