c# asp.net session asynchronous newrelic

c# - NewRelic, controlador http asincrónico y AcquireRequestState



asp.net session (2)

Tengo un problema con un controlador asíncrono en la aplicación web ASP.NET distribuida. Primero permítame explicar un caso de uso:

  • aplicación utiliza IIS 8 en la máquina de win 2012 con .NET Framework 4.5.2

  • la aplicación ha desactivado los módulos de autenticación y sesión a través de web.config como este

    <system.webServer> .... <modules> <remove name="WindowsAuthentication" /> <remove name="Session" /> <remove name="FormsAuthentication" /> </modules> </system.webServer>

  • aplicación utiliza el controlador web asíncrono personalizado para atender la solicitud específica

  • la aplicación tiene un tráfico muy intenso (aproximadamente 50k de solicitudes por minuto por servidor, el controlador asincrónico tiene aproximadamente 10k solicitudes por minuto por servidor, todo rastreado desde NewRelic)
  • la aplicación se distribuye a través de múltiples procesos w3wp (2 procesos w3wp) y múltiples servidores virtuales (aproximadamente 10 servidores)
  • la aplicación tiene una gran cantidad de conexiones

Todas las solicitudes de sincronización normales funcionan bien, pero la solicitud asincrónica que hace un poco más de trabajo (es por eso que usamos la solicitud asincrónica) a menudo es lenta, pero NewRelic informa que es lenta debido a "AcquireRequestState". Ahora he buscado en google y overflow de la pila y este evento está conectado para crear una sesión, pero tenemos sesiones deshabilitadas en web.config. ¿Alguien sabe qué más podría estar haciendo "AcquireRequestState"? ¿Nos falta algún lugar para eliminar el estado de la sesión? Agregar eso de web.config a machine.config no hizo nada ...

Aquí hay un fragmento de una solicitud en NewRelic:

**Slowest components Count Duration % ** AcquireRequestState 1 12,600 ms 100% --> WTF? ExecuteRequestHandler 1 5.01 ms 0% Integrated Pipeline 1 0.334 ms 0% UpdateRequestCache 1 0.3 ms 0% EndRequest 1 0.168 ms 0% AuthenticateRequest 1 0.161 ms 0% Total time 12,600 ms 100%

EDIT: tengo <sessionState mode="Off" /> en web.config ( <system.web> section) así que eso no es así.

AcquireRequestState también es utilizado por el módulo de perfil . ¿Intentaste deshabilitar eso?

<modules> <remove others unwanted modules... /> <remove name="Profile" /> </modules>

He investigado esto porque tuvimos problemas similares, encontré esta publicación en el foro , la respuesta que es interesante es esta:

Desafortunadamente, el problema no es tan simple como simplemente desactivar sessionState. De hecho, una de las frases clave al describir los desafíos con AcquireRequestState es la frase, por ejemplo, el estado de la sesión cuando se trata de cuándo se produce este evento. Al profundizar en esto (en realidad mirando el origen de .NET) podemos ver que esto se llama cuando se ejecuta un manejador de eventos o se crea un objeto RequestNotification. Me atrevo a decir que hay otros métodos y / o eventos que, cuando se los llama, generarán un evento AcquireRequestState. Rastrearlos a todos representa algo así como una lucha. Parece que esto es algo de lo que no se habla mucho fuera de las discusiones de estado de sesión más normalizadas. El lugar más común en el que vemos que se plantea este evento está relacionado con la administración estatal de la sesión. Pero obviamente hay valores atípicos en los que aún se puede plantear este evento. Incluso se puede invocar directamente desde el código de la aplicación. Lo que el agente enfrenta es que puede identificar el evento, pero raramente la fuente. Cuando se genera como parte de la canalización ASP, la única notificación que recibe el agente es que este es un segmento de la transacción. La fuente, o los métodos ejecutados dentro del evento, es algo que el agente rara vez está instrumentando por defecto. Me gustaría poder ofrecerle más información sobre esto. Hay muchas partes móviles dentro de una aplicación .NET, algunas de las cuales involucran al sistema operativo en sí, IIS, la versión de .NET, si los métodos son asíncronos, la configuración del conjunto de aplicaciones, los modos de ejecución, los permisos, etc. Si bien no quiero abrir una segunda lata de gusanos aquí, esto pone de manifiesto el problema con la falta de rastros de pila para 500 errores. El agente proporciona un seguimiento de pila cuando se ofrece y / o está disponible. Donde el rastro de la pila, si uno existe, ocurre dentro de la tubería ASP es extremadamente importante. A veces ocurre antes de que se ejecute cualquier código de aplicación real. En tales casos, el error se informa a la aplicación, que a su vez permite que el agente .NET vea e informe que se produjo un error, pero no se proporcionan otros detalles. El agente simplemente ve que sucedió e informa tanta información como sea posible. Más allá de eso, el agente simplemente no tiene más detalles que pueda ofrecer.

¡Nos dimos por vencidos, por lo que me interesaría saber si lo resuelves!