Любые известные проблемы, касающиеся пустых страниц * .aspx с IIS7?

Question

У меня есть веб-приложение IIS7, которое в основном обслуживает запросы веб-служб. В рамках нашего решения у нас есть два веб-сервера и балансировщик нагрузки, и балансировщик нагрузки периодически запрашивает страницу из каждого из своих блоков балансировки нагрузки. Страница, загружаемая балансировщиком нагрузки, называется «Health.aspx», код не имеет код, а все содержимое файла Health.aspx:

OK

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

Несмотря на то, что здесь потенциально может возникнуть проблема, я хотел бы начать с самих веб-блоков и определить, может ли почти пустая страница * .aspx без кода вызывать периодические проблемы.

Answer 1

«400 ошибок» охватывает широкий спектр потенциальных проблем, от простого не найденного 404 до неверного запроса 401 и запрещенного 403.

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

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

Answer 2

Вы должны создать Health.html и просто использовать его вместо этого. Это также даст вам некоторое представление о том, дает ли ASP.NET 400 проблем или IIS.

Answer 3

Оказывается, что проблема заключалась в простом количестве запросов и несвоевременном времени ответа (или действительно время запроса - наши клиентские соединения очень медленные) для обработки запросов. Запросы на Health.aspx сталкивались с медленными соединениями с клиентами, и значение по умолчанию MaxConcurrentRequestsPerCPU из 12 искусственно ограничивало наше фактическое количество запросов в секунду. Увеличение этого числа до 100 - на основе тщательного тестирования нашего оборудования на предмет нагрузки для нашего конкретного приложения - решило проблему.