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

Мое знание того, как процессы обрабатываются рабочим процессом ASP.NET, является горестно несоответствующим. Я надеюсь, что некоторые эксперты там могут заполнить меня.

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

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

ОБНОВЛЕНИЕ: Наши результаты варьировались. Если бы мы искусственно вызвали исключение OOM (например, путем загрузки большего и большего PDFs в память), то другие потоки, подаваемые тем рабочим процессом, "зависли" бы временно и затем завершились бы, в то время как другие по-видимому никогда не возвращались бы. Спасибо за Ваши ответы.

6
задан Jason Slocomb 14 April 2010 в 20:36
поделиться

4 ответа

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

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

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

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

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

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

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

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

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

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

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

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

Веб-сады

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

Bottom Line

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

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


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

9
ответ дан 10 December 2019 в 02:45
поделиться

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

0
ответ дан 10 December 2019 в 02:45
поделиться

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

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

0
ответ дан 10 December 2019 в 02:45
поделиться

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

0
ответ дан 10 December 2019 в 02:45
поделиться
Другие вопросы по тегам:

Похожие вопросы: