Поиск причины тайм-аута ASP.Net (при длительных операциях) - PullRequest
4 голосов
/ 21 июня 2011

У меня есть веб-приложение asp.net. Он связывается с бизнес-уровнем через WCF. Продолжительная операция с базой данных (занимает два часа). Это обычный синхронный звонок. Изначально я получал исключения, связанные с тайм-аутами WCF. Для этих исключений на странице пользовательского интерфейса было исключение (например, «Socket Timeout»). Я решил эту проблему, используя настройки привязки WCF как в службе, так и в клиенте.

Теперь, спустя (ровно) один час, я получаю сообщение об ошибке в окне браузера. Несмотря на то, что в нашем приложении есть пользовательская страница ошибок, она не показывает настраиваемую ошибку. Поскольку в пользовательском интерфейсе нет исключений, я предполагаю, что это может быть связано с таймаутом ASP.Net, а не с WCF. Я не вижу ни одного релевантного журнала для просмотра событий.

Какими способами / инструментами я могу определить точную причину истечения времени ожидания?

Это настройка параметров broswer / asp.net / настройка iis?

Сообщение об ошибке IE: страница, которую вы ищете, в настоящее время недоступна. Веб-сайт может испытывать технические трудности, или вам может потребоваться изменить настройки браузера. Примечание: внизу написано «Не удается найти сервер или ошибка DNS»

Примечание. Эта функция используется только один раз в месяц. Это функциональность для администратора. Так что для нас хорошо потратить два часа.

Примечание: у меня есть следующая конфигурация WCF. Служба (receiveTimeout = "05:30:00") и Клиент (receiveTimeout = "05:30:00" и sendTimeout = "05:30:00").

Примечание. Невозможно перейти к нашей пользовательской странице ошибки, и исключение не выдается.

Примечание. Я занимаюсь разработкой Visual Studio 2005.

Примечание. WCF самостоятельно размещается для тестирования.

Примечание: это NetTCPBinding в WCF

Некоторые значения конфигурации, используемые в приложении, перечислены ниже:

<httpRuntime maxRequestLength="20000" executionTimeout="900"/>

  <forms loginUrl="Default.aspx" name=".ASPNETAUTH" protection="None" path="/" timeout="30" defaultUrl="Home.aspx">

  </forms>

</authentication>  

и-

<roleManager defaultProvider="MyRoleProvider" enabled="true" 
cacheRolesInCookie="true" cookieName=".ASPROLES" cookieTimeout="30" cookiePath="/"   cookieRequireSSL="false" cookieSlidingExpiration="true" cookieProtection="All">
  <providers>
    <clear/>
    <add name="MyRoleProvider" type="My.AccessControl.ServiceLayer.MyRoleProvider"  />
  </providers>
</roleManager>

Примечание. Я планирую отключить «Показать дружественные сообщения об ошибках HTTP» в IE. Я также планирую сделать customErrors mode = ”Off” в system.web для дальнейшего тестирования.

Ответы [ 5 ]

5 голосов
/ 22 июня 2011

Сначала , браузер будет ждать так долго, пока веб-сервер ответит, и начнет выдавать ответ.IE 7/8, я считаю, залог через 60 минут.Не знаю о IE 9. Подробнее см. KB181050 .Firefox, Chrome, Safari, Opera, скорее всего, различаются по тому, как долго они готовы ждать, пока не решат, что там нет сервера.

Честно говоря, я думаю, что 60 минут - это ужасно долго, прежде чем принять решениечто сервер не собирается отвечать.5 минут должно быть более чем достаточно.Что бы вы подумали, если бы запросили веб-страницу и не получали ответа от сервера более минуты или двух: разве вы обычно не предполагаете, что сервер сбит с толку, и отмените запрос?

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

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

С какой стати вы ожидаете, что ваши пользователи (и их веб-браузер) будут зависать в течение 2+ часов в ожидании HTTP-запроса?

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

В браузере клиента создайте такой запрос через сообщение AJAX. Позвольте JavaScript на стороне клиента использовать возвращенный билет дляопрашивайте каждые 30 секунд или около того, пока запрос не будет выполнен. Вуаля! Больше нет тайм-аутов браузера.

2 голосов
/ 21 июня 2011

Если вы можете разместить его на сервере IIS, вы можете попробовать использовать модуль FailedRequestTracing.

http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/

Я уже использовал его для устранения таймаутов ранее.

0 голосов
/ 22 июня 2011

Вся концепция ожидания по HTTP для того, что вы сами назвали операцией ДВА ЧАСА, ошибочна из git-go.Как уже упоминалось другими авторами, вам нужно переосмыслить свою стратегию.Начать его с какого-либо процесса в очереди, а затем предоставить пользователям какой-либо метод, чтобы либо опросить о завершении, либо даже отправить им уведомление по электронной почте со ссылкой в ​​нем, - это один из способов.

Иди с потоком.

0 голосов
/ 22 июня 2011

Вам лучше реализовать дуплексный сервис для уведомления между WCF и ASP.net и AJAX для уведомления между клиентом и веб-сервером

0 голосов
/ 22 июня 2011

Может ли сеанс быть тайм-аут или (веб) приложение закрывается на один час?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...