2012-01-19 17 views
8

aquí está mi problema:IIS7 deja de funcionar después de 5 solicitudes

acabo de ser introducido en una # masivo proyecto asp.net C y he sido acusado de fijación de algunos problemas de rendimiento (no es mi área de especialización). Más específicamente después de 5 - 7 redirecciones/llamadas ajax, el servidor web deja de responder y la página completa (y finalmente el navegador) se congela.

No creo que esto sea un problema de codificación ya que he configurado puntos de interrupción en unas pocas páginas (método Page_Load) y después de las 5 solicitudes ni siquiera llega a los puntos de ruptura.

No creo que esto esté relacionado con this issue ya que he aumentado las conexiones máximas del navegador por parámetro de servidor y obtuve el mismo comportamiento. Además, después de que estos 5 soliciten en un navegador IE, la aplicación también deja de funcionar en FF.

Esto no es un problema de recursos ya que el proceso de w3wp.exe nunca excede 500MB de memoria.

Una cosa que he notado al usar Fiddler y otras herramientas para monitorear las solicitudes es que el servidor tarda mucho tiempo al cargar archivos de imagen (png, jpg). No sé si esto es relevante.

He habilitado el seguimiento de solicitudes fallidas en el servidor y lo único que he notado es que algunas solicitudes fallan con un error de error de 401, incluso he configurado la Autenticación anónima como habilitada. Aquí es el mensaje exacto

MODULE_SET_RESPONSE_ERROR_STATUS 

ModuleName  ManagedPipelineHandler 

Notification 128 
HttpStatus  401 
HttpReason  Unauthorized 
HttpSubStatus 0 
ErrorCode  0 

ConfigExceptionInfo 

Notification EXECUTE_REQUEST_HANDLER 

ErrorCode  The operation completed successfully. (0x0) 

Este mensaje es a veces lanza con ModuleName: ScriptModule

ya he perdido 2 días en esta cosa y me estoy quedando sin ideas por lo que cualquier sugerencia sería apreciada.

+9

cinco solicitudes deberían ser suficientes para cualquiera. –

+2

Su razón para la hipótesis de que no es un problema de codificación no parece sólida. –

+0

@Matt - nada útil, pero votado para el funneh. –

Respuesta

1

He resuelto el problema finalmente. Esto es lo que hice:

  1. experimentó con la configuración de IIS y el reciclaje App_Pool y notamos que no hay nada malo en la forma en que maneja las peticiones que llegan en realidad.

  2. Me centré en el módulo Http.sys y noté que en los archivos de registro había una gran cantidad de errores Timer_ConnectionIdle y Client_Reset.

  3. Después de más experimentación y muchas búsquedas en Google, accidentalmente encontré este answer y resolvió mi problema. Como la respuesta sugiere, el problema fue causado por el antivirus AVG instalado y configurado incorrectamente en el servidor.

Gracias por toda la ayuda y sugerencias.

0

Si se trata de llamadas ajax que hacen que su navegador se congele, asegúrese de que no sean blocking llamadas ajax.

+0

La mayoría de las llamadas Ajax se realizan desde JQuery con controladores Http y la mayoría son asincrónicas y con un tiempo de espera de 500ms. – Constantin

+0

Intentaré aumentar el tiempo de espera a unos 15 segundos. Podría ser la cantidad real de conexiones que está causando problemas. 500ms puede causar problemas de usabilidad si un usuario tiene una conexión a Internet lenta de todos modos. – Matthew

+0

Además, si está ejecutando un servidor IIS local en Windows 7 o Vista, creo que la cantidad máxima de conexiones permitidas de una vez es 10. – Matthew

4

Como cualquier gran problema genérico, la mejor apuesta para diagnosticar el problema es descubrir cómo dividir el problema en partes más pequeñas, cómo plantear la hipótesis y cómo validar o invalidar sus hipótesis. Mi primera inclinación sería formular la hipótesis de que los procesos del lado del servidor en este particular están tardando mucho tiempo, lo que hace que las solicitudes de sus clientes se bloqueen, haciendo que todo parezca congelado.

A partir de ahí, intentaría replicar los procesos del lado del servidor de larga ejecución creando pruebas aisladas del lado del cliente; quizás, si las URL son HTTP, probaría las mismas URL individualmente. Si fueran publicaciones HTTP, crearía un formulario de prueba aislado si es factible para ver qué ocurre con cada solicitud. Si se encuentra un proceso de servidor de ejecución larga, entonces tiene un punto de partida.

Si no hay procesos largos del lado del servidor que se ejecutan, entonces pueden ser problemas de JavaScript/codificación del lado del cliente que necesitan ser examinados. Pero definitivamente cuando trabajas en un proyecto grande y desconocido, tu mejor opción es descubrir cómo descomponer el problema en componentes más pequeños que luego puedan probarse

0

Anexando la respuesta de Shan, que es buena.

En primer lugar, obviamente hay un problema de código ya que este no es un comportamiento 'normal' para IIS.

Dicho esto, debe aislarlo como indica Shan.Por ejemplo, dado que el servidor ya no acepta conexiones, podemos eliminar JavaScript como el origen del problema y relegarlo a ser solo un síntoma.

Normalmente, cuando un proceso de trabajo gira hacia el espacio de esta manera, se debe a un ciclo infinito o a un problema donde varios hilos intentan bloquear el mismo recurso. Apuesto a que si lo dejas funcionar el tiempo suficiente, IIS esperará, matará y reiniciará el proceso.

Teniendo esto en cuenta, debe buscar cualquier tipo de basura multiproceso (que le recomiendo no hacer en un servidor web) o para cualquier cosa que indique un ciclo infinito ajustado. Un ciclo se hará evidente si ejecuta las solicitudes individualmente. Un problema de subprocesos múltiples solo aparecerá si se produce una colisión.

Ejecuta varios contadores de rendimiento en el servidor web. Además, una vez que se bloquea, déjalo reposar de esa manera por un tiempo. Una vez que IIS realiza su propio reinicio en el proceso de trabajo, busque indicadores en el registro de eventos.

Cuestiones relacionadas