Что происходит с другими пользователями, если .Сбой рабочего процесса NET?

Question

Мои знания о том, как процессы обрабатываются ASP.Процесс Net worker крайне неадекватен.Я надеюсь, что кто-нибудь из местных экспертов сможет ввести меня в курс дела.

Если я завершу работу рабочего процесса с помощью System.Исключение OutOfMemoryException, каким будет пользовательский опыт для других пользователей, которые обслуживались тем же процессом?Получат ли они пустой экран?ошибка 503?

Я собираюсь попытаться протестировать этот сценарий с некоторыми другими ребятами в нашей лаборатории, но я подумал, что выложу это там.Я буду информировать вас о наших результатах.

Обновить:Наши результаты были разными.Если бы мы искусственно вызвали исключение ООМ (например, загружая все большие и большие PDF-файлы в память), другие потоки, обслуживаемые этим рабочим процессом, временно "зависли" бы, а затем завершились, в то время как другие, по-видимому, никогда бы не вернулись.Спасибо вам за ваши ответы.

Answer 1

W3WP.exe это процесс

IIS запускает все веб-приложения в общем рабочем процессе - w3wp.exe.Независимо от того, пишете ли вы в ASP.NET, или ISAPI, или какой-либо другой среде, процесс, который обслуживает веб-запрос, является w3wp.exe.В случае ASP.NET w3wp.exe загружает ASP.NET JIT-скомпилированные библиотеки DLL и обслуживает запросы через них.В других случаях это работает по-другому.Но ключевой момент в том, что w3wp.exe это процесс.Эта модель началась в IIS6.0 и продолжается в IIS7.0.

Неожиданные Сбои

Если по какой-либо причине произойдет неожиданный сбой W3WP.exe, все транзакции, которые он обрабатывал, скорее всего, получат 500 ошибок (ошибка сервера).IIS запустит новый рабочий процесс на своем месте (MS называет это "Мониторингом здоровья".), что означает, что веб-приложение будет продолжать работать.Пользователи, у которых на момент сбоя процесс не обрабатывал запрос, будут не знать ни о чем из этого.

Ошибка HTTP 500, которую клиент получает в этом случае, будет неотличима от ошибки 500, которую клиент получает в случае ошибки приложения, скажем, неперехваченного исключения в коде вашего приложения ASPNET.

Для тех запросов, которые находились в процессе сбоя, восстановить их невозможно.Они приведут к появлению 500 ошибок в браузере.Загруженность сервера 503 возникает из-за того, что IIS активно отказывается от подключения из-за порогового значения количества подключений.Значение 503 не является результатом сбоя приложения, поэтому не следует ожидать появления значения 503 для транзакций в процессе выполнения в сценарии нехватки памяти и сбоя.В сильно загруженной системе вы можете увидеть 503-е, когда происходит сбой процесса и перезапуск, в качестве вторичного эффекта.Если это действительно то, что вы видите, вам нужен больший запас прочности для обработки нагрузки в условиях одиночной ошибки.

Очередь запросов

IIS использует метод передачи данных для запросов.По мере поступления на сетевой уровень (Http.sys) они помещаются в очередь для получения рабочим процессом.Любые запросы, ожидающие обработки WP в очереди IIS, останутся без изменений, хотя они могут увидеть небольшое временное увеличение задержки (времени обслуживания) из-за конкуренции ресурсов, поскольку на сервере выполняется на один процесс меньше.Время ожидания в этой очереди обычно очень-очень короткое в системе, которая настроена должным образом.

Именно тогда, когда эта очередь заполнится, вы увидите 503 ошибки.

Автоматический перезапуск W3WP.exe

IIS имеет функцию автоматического перезапуска (или "няня"), с помощью которой он перезапускает рабочие процессы после того, как они превысили настроенные пороговые значения, например, объем памяти, количество запросов или время выполнения.Во всех этих случаях IIS приостанавливает работу и перезапускает рабочие процессы при достижении настроенного порогового значения.Эти активные перезапуски обычно не приводите к каким-либо сбоям в выполнении запросов.Когда IIS решает, что необходим перезапуск рабочего процесса, он предотвращает поступление любых новых запросов на этот остановленный WP. Существующие запросы удаляются:любые транзакции в полете в этом WP разрешается выполнять в обычном режиме.Когда все запросы в WP завершаются, WP умирает, и IIS запускает новый на его месте.Затем этот новый процесс немедленно начинает получать новые запросы из очереди отправки.Все это прозрачно для пользователей или браузеров.

Я говорю обычно потому что вполне возможно, что рабочий процесс стал по-настоящему больным в то же время, когда был достигнут порог.В этом случае w3wp.exe может не отвечать IIS внутри настроенный тайм-аут "покоя", и, таким образом, IIS должен в конечном итоге завершить процесс, даже если он не сообщил, что все его запросы в процессе выполнения выполнены.Это должно быть чрезвычайно редко, потому что это два разных исключительных состояния, но это случается.В этом случае запросы в полете снова выдадут 500 ошибок.

Веб - сады

Также - IIS допускает несколько рабочих процессов на одном сервере. MS называет это "веб-садом"., игра слов из "веб-фермы".Если у вас настроен web garden, то транзакции, обслуживаемые w3wp.exe экземплярами, отличными от отказавшего, останутся неизменными.Однако "Незатронутый" предполагает, что ошибка нехватки памяти локализована, а не является общесистемной проблемой.

Итог

Суть в том, что нет никакой замены вашему собственному тестированию.Параметры конфигурации довольно широки - от пороговых значений перезапуска до веб-садов и так далее.Кроме того, режимы сбоя, как правило, довольно сложны и разнообразны, будь то память, тайм-аут, слишком большая занятость и так далее.Вы захотите понять, чего ожидать.

ps:эти вопросы и ответы действительно относятся к serverfault.com !!

---

ссылки:
http://blogs.iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx

Answer 2

Будет запущен новый рабочий поток, и пользователь не будет знать, что что-то произошло.Если только он полностью не отключится из- за быстрого сбоя (http://technet.microsoft.com/en-us/library/cc779127 (WS.10).aspx)

Answer 3

Если это ситуация с нехваткой памяти, iis обычно просто перерабатывает пул приложений.

Answer 4

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

Однако, если ваше приложение использует переменные сеанса с состоянием сеанса In-Proc, все переменные сеанса для всех пользователей будут потеряны при перезапуске пула приложений.Это может оказать или не оказать негативное влияние на пользователей, в зависимости от того, что вы делаете с переменными сеанса.Вы можете избежать этого, переключившись на сервер состояний или хранилище сеансов SQL Server.