¿Cómo puedo medir la respuesta y el tiempo de carga de una página web?

Question

Necesito crear una aplicación de formularios de Windows para medir el tiempo que lleva cargar completamente una página web, ¿cuál es el mejor enfoque para hacerlo?

El objetivo de esta pequeña aplicación es controlar algunas páginas de un sitio web, en un intervalo predeterminado, para poder saber de antemano si algo está yendo mal con el servidor web o el servidor de la base de datos.

Otros detalles:

no puede utilizar una aplicación comercial, necesito desarrollar esto con el fin de ser capaz de guardar los resultados en una base de datos y crear una serie de informes sobre la base de esta información.

La solución webrequest parece ser el enfoque que voy a utilizar, sin embargo, sería bueno poder medir el tiempo que lleva cargar completamente la página (imágenes, css, javascript, etc.) . ¿Alguna idea de cómo se podría hacer eso?

Answer 1

Si solo desea registrar cuánto tiempo lleva obtener la fuente de página básica, puede ajustar una HttpWebRequest alrededor de un cronómetro. P.ej.

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(address); 

System.Diagnostics.Stopwatch timer = new Stopwatch(); 
timer.Start(); 

HttpWebResponse response = (HttpWebResponse)request.GetResponse(); 

timer.Stop(); 

TimeSpan timeTaken = timer.Elapsed; 

Sin embargo, esto no tendrá en cuenta el tiempo para descargar contenido adicional, como imágenes.

[edit] Como alternativa a esto, puede usar el control WebBrowser y medir el tiempo entre la ejecución de un evento .Navigate() y el evento DocumentCompleted de la activación. Creo que esto también incluirá la descarga y el tiempo de renderización de contenido adicional. Sin embargo, no he usado el control WebBrowser una gran cantidad y solo no sé si debe borrar un caché si está solicitando repetidamente la misma página.

Answer 2

Se puede utilizar un software como éstos:

http://www.cyscape.com/products/bhawk/page-load-time.aspx

http://www.trafficflowseo.com/2008/10/website-load-timer-great-to-monitor.html

Google será útil para encontrar el que mejor se adapte a sus necesidades.

Answer 3

• http://www.httpwatch.com/
• Firebug NET pestaña

Answer 4

Algo como esto probablemente funcionaría bien:

System.Diagnostics.Stopwatch sw = new Stopwatch() 
System.Net.HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create("http://www.example.com"); 
// other request details, credentials, proxy settings, etc... 

sw.Start(); 
System.Net.HttpWebResponse res = (HttpWebResponse)req.GetResponse(); 
sw.Stop(); 

TimeSpan timeToLoad = sw.Elapsed; 

Answer 5

Si estás usando Firefox instalar la extensión Firebug encontrado en http://getfirebug.com. A partir de ahí, elija la pestaña de red, y le permitirá saber el tiempo de carga/respuesta para todo en la página.

Answer 6

Dependiendo de cómo la frecuencia necesita hacerlo, tal vez puede intentar usar Selenium (una herramienta de prueba automatizada para aplicaciones web), dado que los usuarios internamente un navegador web, tendrá una medida bastante estrecha. Creo que no sería demasiado difícil usar la API de Selenium desde una aplicación .Net (ya que incluso puedes usar Selenium en pruebas unitarias).

Medir este tipo de cosas es complicado porque los navegadores web tienen algunas particularidades cuando se descargan todos los elementos de páginas web (JS, CSS, imágenes, iframes, etc.) - este tipo de particularidades se explican en este excelente libro (http://www.amazon.com/High-Performance-Web-Sites-Essential/dp/0596529309/) .

Una solución casera probablemente sería demasiado compleja para codificar o no cumpliría algunas de esas particularidades (medir el tiempo empleado en descargar el html no es suficiente).

Answer 7

Una cosa que debes tener en cuenta es el caché. Asegúrese de medir el tiempo de descarga desde el servidor y no desde el caché. Deberá asegurarse de haber desactivado el almacenamiento en caché del lado del cliente.

También tenga en cuenta el almacenamiento en memoria caché del lado del servidor. Supongamos que descarga el ritmo a las 9:00 AM y tarda 15 segundos, luego lo descarga a las 9:05 y tarda 3 segundos, y finalmente a las 10:00 toma 15 segundos nuevamente.

Lo que podría estar sucediendo es que a las 9 el servidor tuvo que renderizar la página porque no había nada en la memoria caché. A las 9:05, la página estaba en el caché, por lo que no era necesario volver a generarla. Finalmente, por 10, el caché se había borrado, por lo que el servidor necesitaba volver a generar la página.

Recomiendo encarecidamente que compruebe el complemento YSlow para FireFox que le dará un análisis detallado de los tiempos necesarios para descargar cada uno de los elementos en la página.

Answer 8

me escribió una vez al experimentalprogram que descarga una página HTML y los objetos que hace referencia (imágenes, marcos flotantes, etc.).

Más complicado de lo que parece porque hay negociación de HTTP, algunos clientes Web obtendrán la versión SVG de una imagen y PNG, muy diferente en tamaño. Lo mismo para <object>.

Answer 9

A menudo me enfrento a un problema bastante similar. Sin embargo, tomo un enfoque ligeramente diferente: en primer lugar, ¿por qué debería preocuparme por el contenido estático? Me refiero, por supuesto, es importante para el usuario, si toma 2 minutos o 2 segundos para una imagen, pero ese no es mi problema DESPUÉS de que desarrollé completamente la página. Estas cosas son problemas durante el desarrollo y después del despliegue no es el contenido estático, pero es el elemento dinámico que normalmente ralentiza las cosas (como dijiste en el último párrafo). Lo siguiente es, ¿por qué confías en que tantas cosas se mantengan constantes? Si alguien en su red activa un programa p2p, el enrutamiento falla o su ISP tiene algunos problemas, las estadísticas del servidor ciertamente bajarán. ¿Y qué dice su punto de referencia para un usuario que vive en todo el mundo o simplemente utiliza un ISP diferente? Todo lo que digo es que usted está evaluando SU punto de vista, pero eso no dice mucho sobre el rendimiento de los servidores, ¿verdad?

¿Por qué no dejar que el sitio/servidor en sí determine cuánto tiempo llevó cargar? He aquí un pequeño ejemplo escrito en PHP:

function microtime_float() 
{ 
    list($usec, $sec) = explode(" ", microtime()); 
    return ((float)$usec + (float)$sec); 
} 

function benchmark($finish) 
{ 
    if($finish == FALSE){ /* benchmark start*/  
    $GLOBALS["time_start"] = microtime_float(); 
    }else{ /* benchmark end */  
    $time = microtime_float() - $GLOBALS["time_start"]; 
    echo '<div id="performance"><p>'.$time.'</p></div>'; 
    } 
} 

Se añade al final de la página el tiempo que se tardó en construir (oculto con CSS). Cada dos minutos copio esto con una expresión regular y lo analizo. Si este tiempo aumenta, sé que hay algo mal (¡incluido el contenido estático!) Y a través de un RSS Feed me informo y puedo actuar.

Con firebug sabemos el rendimiento "normal" de un sitio cargando todo el contenido (fase de desarrollo). Con el punto de referencia obtenemos la situación actual del servidor (incluso en nuestro teléfono celular). DE ACUERDO. ¿Qué sigue? Tenemos que asegurarnos de que todos/la mayoría de los visitantes estén teniendo una buena conexión. Encuentro esta parte realmente difícil y estoy abierto a sugerencias. Sin embargo, trato de tomar los archivos de registro y hacer ping a un par de IP para ver cuánto tarda en llegar a esta red. Además, antes de decidirme por un ISP específico, trato de leer sobre la conectividad y las opiniones de los usuarios ...