Если запросы к приложению не выполняются, то количество ресурсов / подключений / и т. Д ... будет равно нулю?

стория
В прошлом месяце наша команда разработчиков создала новое приложение asp.net 3.5 для размещения на нашем производственном веб-сайте. Как только мы завершили работу, мы попросили группу, которая управляет сервером, скопировать приложение на наш производственный сайт и настроить виртуальный каталог как новое приложение.

27.12.2010 два публичных «Gineau Pigs» были выбраны для использования приложения, и оно отлично работало. 30.12.2010 г. мы получили уведомление от внутреннего персонала о том, что когда этот сотрудник пытался получить доступ к приложению (это был владелец бизнес-процесса), они получили сообщение «Серверное приложение недоступно».

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

Я немного погуглил, так как не люблю, когда меня обвиняют в чем-то. Я обнаружил, что сообщение «Серверное приложение недоступно» также будет отображаться, когда у вас есть несколько приложений, использующих разные платформы, и вы не помещаете их в разные пулы приложений.

Технические детали - Дерево структуры нашего сайта

Main Website <-- ASP Classic
         +-Virtual Directory(ExtensionRequest) <-- ASP 3.5 

Из нашей группы поддержки серверов:

'Рассмотрены журналы сервера и настройки веб-сайта в IIS. Пришлось сбросить пул приложений, так как он не работал должным образом. Это исправило сайт, и теперь он снова в сети. Мы пошли дальше и создали пул приложений для веб-расширений, чтобы он был изолирован от основного пула сайтов. В прошлом мы видели, как другие приложения делали это, когда соединение оставалось открытым, а пул заполнялся. Рекомендую просмотреть код сайта, чтобы убедиться, что нет открытых соединений. '

Настоящий вопрос: Что на самом деле вызвало сбой? Разве соединение не остается открытым, проблема ASP Classic? Разве приложение ExtensionRequest не нужно было бы использовать (более двух раз), чтобы соединения оставались открытыми? Является ли более вероятным, что сбой вызван тем, что они вообще не удосужились настроить новое приложение в своем собственном пуле приложений?

Извините за долгую затяжку

 Kev12 янв. 2011 г., 13:45
Я расширил свой ответ, см. Последнюю часть.

Ответы на вопрос(2)

Причин может быть много (слишком много используемых ресурсов, вызов за пределами .NET вызвал сбой и т. д.). Я бы посмотрел в журнале событий и посмотреть, если вы можете найти что-то там.

Если вы используете разные версии .NET, вам определенно нужны отдельные пулы. Если у вас есть возможность, я бы порекомендовал отдельные пулы для каждого приложения (даже если в одной версии .NET).

Что касается «закрытия соединения» (я предполагаю, что вы имеете в виду соединение с базой данных). Если вы создаете соединения «низкого уровня» (то есть SqlConnection, SqlCommand), убедитесь, что вы заключаете их в оператор «using», иначе ваш пул соединений может заполниться. По моему опыту, вы должны получать регулярные ошибки .NET в этом случае. Если вы используете ORM, это не должно быть проблемой.

Редактировать:

Если вы не можете найти ничего полезного в журнале событий, вы можете попробовать это:http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/

 Doug Chamberlain10 янв. 2011 г., 15:40
Если запросы к приложению не выполняются, то количество ресурсов / подключений / и т. Д ... будет равно нулю?
Решение Вопроса

жений сервера и HTTPERR сервера за период, когда сервер сообщал об этих ошибках.

Без них было бы трудно предположить, что является основной причиной проблемы.

Обновить:

ОП неправильно пометил свой вопрос, поэтому следующий раздел больше не применяется. Однако я оставлю это на месте, потому что я думаю, что информация полезна для тех, кто сталкивается с этими проблемами и, возможно, думает о переходе на IIS7.x.

Вы правы, что запуск двух разных .NET Framework в одном и том же пуле приложений может привести к этим ошибкам, но это скорее всего вы увидите в Windows 2003 / IIS6, а не в Windows 2008 / IIS7.

В IIS7 используется несколько иной подход к указанию, какая версия .NET Framework загружена и определяется пулом приложений.managedRunTimeVersion свойство. Когда запросы обрабатываются IIS / ASP.NET, отображение обработчика сайта используетpreCondition атрибут, определяющий, когда загружать требуемый обработчик (что-то вроде сопоставления скриптов в предыдущих версиях IIS).

Этот механизм предотвращает загрузку неверной версии во время выполнения в рабочий процесс пула приложений.

Таким образом, если пул приложений настроен для запуска версии .NET Framework v4.0, будет загружаться только эта версия, даже если ваше приложение собрано для v2.0.

Здесь есть отличная статья о том, как это работает:

Achtung! Предварительные условия IIS7

Примерно на полпути в разделе «Обработчики» объясняется, почему опасность случайной загрузки неправильной версии .NET в пул смягчаетсяpreCondition характерная черта.

Ошибка недоступности серверного приложения обычно означает, что произошло что-то катастрофическое (например, загрузка фильтра ISAPI неправильной версии ASP.NET в уже запущенный рабочий процесс).

Не закрытие соединений SQL вряд ли вызовет серьезную ошибку такого типа. Вы бы, скорее всего, увидели бы желтый экран ошибок времени выполнения смерти, если бы это было так. Заканчивание соединений SQL обычно не приводит к изгибу ASP.NET настолько, что весь сервис опережает себя.

Моим главным подозрением была бы проблема с разрешениями, когда удостоверение пула приложений не могло правильно обращаться к папкам приложений. Но это только догадка.

Опять же, вам нужно получить журналы событий приложений и системы и журналы HTTPERR (они находятся в%systemroot%\System32\LogFiles\HTTPERR, Это будет содержать подсказки и факты о том, что пошло не так.

Обновление 2:

В Windows 2003 / IIS6, если у вас есть два приложения с разными версиями ASP.NET, которые находятся в одном пуле, выбудем получите эту ошибку. По моему опыту (я работаю на веб-хостинга), это основная причина этой печально известной страницы ошибки:

Также есть контрольное событие, зарегистрированное в журнале событий приложений:

Event Type: Error
Event Source:   ASP.NET 2.0.50727.0
Event Category: None
Event ID:   1062
Date:       12/01/2011
Time:       12:31:43
User:       N/A
Computer:   KK-DEBUG
Description:
It is not possible to run two different versions of ASP.NET in the same 
IIS process. Please use the IIS Administration Tool to reconfigure your
server to run the application in a separate process.

Хотя ваше корневое приложение может быть написано не в ASP.NET, вероятно, что-то вызвало загрузку другой версии платформы в пул приложений вашего сайта.

есть жуликweb.config в корне ... это вызовет ASP.NET для загрузкив картах сценариев сайта есть сопоставление с ASP.NET 1.1 (менее вероятно, но возможно)

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

 Doug Chamberlain10 янв. 2011 г., 15:37
Я неправильно пометил свой вопрос. Это сервер 2003 и IIS6.
 Doug Chamberlain12 янв. 2011 г., 14:15
@Kev Теперь это ответ. это на самом деле v1.1 и v3.5 Спасибо за отличное объяснение. Я буду держать подбородок, зная, что ониособый люди, с которыми я работаю. (те же люди, которые сказали мне, что xxx.yyy.com не является поддоменом yyy.com)
 Kev12 янв. 2011 г., 14:03
@joel - Я очень хорошо знаю, что 2.0 и 3.5 находятся на одной базе. Если это размещенная служба, то, по всей вероятности, если исходный сайт был создан до версии 2.0, он будет работать в пуле приложений 1.1. Некоторые из нас не заставляют всех переходить на новую платформу (мы используем/noaspupgrade переключитесь с помощью установщика 2.0) и вместо этого предоставьте инструменты панели управления пользователя, которые позволят клиентам выбрать свою версию ASP.NET и переключить сайт в совместимый пул приложений. Я склонен сказать, что у того, кто управляет сервером, были проблемы с пальцами в тот день. Это случается
 Joel Etherton12 янв. 2011 г., 13:53
@Kev / @Doug Chamberlain - Asp.Net 3.5 и 2.0 работают на одной основе (2.0). 3.5 имеет дополнительные / расширенные .dll, но приложения 3.5 и 2.0 должны иметь возможность жить вместе, если ни один сайт не использует одни и те же объекты. Поскольку это обновление, вероятно, что оба приложения, работающие в одном пуле приложений, загружают общие объекты, которые расширяются по-разному. Возможно, версия 2.0 загружает MyClass в память, а затем версия 3.5 пытается привести (и успешно) из объекта приложения. Когда версия 2.0 возвращается, чтобы вернуть свой объект, он взрывается, поскольку приведение больше не действует.
 Joel Etherton12 янв. 2011 г., 13:55
@Kev / @Doug Chamberlain - продолжение - Обычно это не приводит к остановке службы, но пулы приложений по умолчанию имеют параметр «Включить быструю защиту от сбоев», который будет отлавливать ошибки, возникающие в быстрой последовательности, и выводить пул приложений. вниз, чтобы защитить сервер. Это будет сопровождаться, как описано выше, событиями в журнале событий, но ошибка будет более общей, указывая только на то, что процесс w3wp.exe неожиданно завершился.

Ваш ответ на вопрос