Pregunta

Tenemos una aplicación ASP.Net, que se comporta de forma extraña bajo IIS6. La aplicación en sí es sencillo ASP.Net 2.0 acuerdo de formularios web, nada demasiado raro está pasando ahí (hay módulos HTTP par en la tubería, pero no los consideraría extraño :)). Lo que no entiendo es los tiempos de ejecución de la página, o, más específicamente, la diferencia entre el tiempo reportado por ASP.Net rastreo (trace.axd) y observado por el cliente (violinista). Cuando la aplicación se ejecuta en la caja de desarrollador (WinXP, IIS5.1), los tiempos reportados por ASP.Net y violinista están muy cerca:

Page exec time             :  0.0919834
Fiddler Total Sequence time:  0.1560980 

Puedo entender 60ms se gastan consiguiendo el valor de 5 KB de datos de IIS a Fiddler (ambos de los cuales se ejecutan en la misma máquina, por cierto). Ahora, cuando movemos el código al servidor (Win2k3, IIS6), el panorama cambia drásticamente:

Page exec time             :  0.1702014
Fiddler Total Sequence time:  0.5156283 

Esta es la misma página, y el violinista está ejecutando de nuevo en la misma máquina con el código. ¿Por qué de repente toma 350 ms para entregar el mismo 5 KB?

PS. En ambas máquinas de los resultados se obtienen mediante el acceso al URL a través de nombre de host de la máquina real, por ejemplo, http: //machinename/app/page.aspx (en contraposición a http: //localhost/app/page.aspx ).

PPS. En cuanto a la configuración, las configuraciones de una caja de dev y el servidor estén lo más cerca que podríamos hacerlos - ambos utilizan la misma web.config. Tanto golpeó la base de datos (SQL Server) con autenticación integrada, y, en consecuencia, la aplicación se ejecuta bajo una cuenta de dominio. La aplicación utiliza la autenticación de formularios, y no suplanta (es decir, que siempre se ejecuta bajo la misma cuenta). Ahora, la forma en que esto funciona en IIS 5 es diferente de IIS6 - en IIS5 se especifica la cuenta en la etiqueta en el machine.config, y en IIS6 es el escenario AppPool. La configuración parece bastante típico para ambos entornos, y no puedo imaginar lo que causa retrasos 350ms ...

¿Fue útil?

Solución

Después de gastar uno de los pocos incidentes de soporte preciosos que tenemos con nuestra suscripción a MSDN, por fin sabemos la respuesta correcta a "en el que se pasó todo este tiempo" cuestión. En resumen, el tiempo que se gasta en los módulos HTTP que tenemos en nuestra cartera. Las mediciones de tiempo reportados por ASP.Net Trace.axd registro sólo el tiempo pasado en la página .aspx en sí, los módulos son no incluidos.

Una forma fácil de determinar esto (y ver cuánto tiempo hace cada módulo tienen que hacer su cosa) es utilizar el ETW (seguimiento de eventos para Windows). Aquí está el explicación (sospecho fuertemente que este post fue escrito después de que miraron nuestro caso :)) una cosa que puedo añadir a la excelente descripción anterior es que he utilizado la SvcTraceViewer en lugar de LogParser para analizar la salida de rastreo.

Actualización: el enfoque anterior también funciona en Windows Server 2008, sólo asegúrese de que usted tiene rastreo instalado .

Otros consejos

Hacer un trazado de ruta en la URL que está llamando y compararlas. Mi apuesta con el ordenador de desarrollo se aloja interna a la máquina, pero en la máquina de producción que vas externo y luego volver a través de la dirección IP.

Si este es el caso, trate de añadir esto a su archivo de hosts (C: \ Windows \ system32 \ drivers \ etc \ hosts

www.mysite.com    127.0.0.1

Esto hará que su solicitud no se aventura fuera de la máquina para realizar la solicitud. Debería ver los tiempos de respuesta para comenzar a venir en línea entre sí.

Actualizar

Teniendo en cuenta las nuevas actualizaciones. Si el servidor está bajo carga, mientras que las pruebas sobre la producción Esto podría explicar la diferencia, ya que está activamente tratando de entregar más solicitudes que el equipo de desarrollo que sólo está tratando de entregar 1.

O podría ser debido a que se está probando dos versión diferente de IIS, 5.1 en XP y 6.0 en 2003. En realidad, no puede dar cuenta de las diferencias a menos que los dos ambientes están ejecutando el mismo software.

Es la aplicación que se ejecuta en configuraciones de liberación idénticos en ambas cajas?

EDIT: La canalización de solicitud ha cambiado enormemente entre IIS5 y IIS6, trace.axd sólo se va a ver la parte de ASP.NET de la misma, no el nuevo grupo de aplicaciones y componentes HTTP.SYS

.

Me imagino que la configuración se puede ajustar en IIS6 un poco, pero es probable que están mirando a la diferencia de un servidor web ligero no producción (IIS 5) y un servidor web robusto con grupos de aplicaciones individuales para administrar y más capas de abstracción.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top