Reportes y contadores a analizar después de un LoadTest en VS2008

Este es uno de los resúmenes, que nos arroja el Team Test:
A continuación el tipo de análisis que debes hacer, luego que termina la carga. Los siguientes imágenes se obtienen haciendo clic sobre la traza de contadores, dentro de la herramienta Team Test (cuando finaliza la carga), por supuesto debes tener en cuenta adicionar los contadores apropiado, y aportar un buen analisis:

Indicador General

A continuación se presenta el total de las solicitudes, y las peticiones por segundo: En el contador de carga de usuarios podemos visualizar como se fue incrementando 5 usuarios a 50 en el primer minuto con los 30s de la prueba.(Haciendo uso de la carga completa de usuarios virtuales). También podemos observar el número de solicitudes por segundo y ver que número de errores presentados durante la prueba en este caso con valor 1.

Indicador de Procesador y Memoria

Servidor WEB (10.1.5.116):En el siguiente gráfico podemos observar, que el procesador se mantuvo en un promedio de %32 y tuvo 3 picos de %89 lo cual es normal, al no tratarse de un valor constante. Su uso de memoria se mantuvo en un 30%. Es importante resaltar que el proceso w3wp en el servidor de mantiene en un intervalo de 200m a 230m.

Servidor BASE DE DATOS(10.1.5.119):En el siguiente gráfico podemos observar, que el procesador se mantuvo en un promedio de %3 este no presenta ningún pico. Su uso de memoria se mantuvo en un 14%

Indicadores IIS

En el siguiente gráfico podemos observar, que se presentaron 8 peticiones en cola (Requests Queued). También podemos ver a nivel de ASP NET, no se presentaron solicitudes rechazadas (Requests Rejected) ni reinicios del proceso W3p (Worker Process Restarts) utilizado por la aplicación.

En los últimos 30s, los requerimientos se empiezan a encolar (Requests Queued), esperando una respuesta, por defecto en el machine.config el máximo es 100. Cuando se sobre pase este valor, entonces el servidor Web habrá alcanzado el límite de requerimientos concurrentes que puede procesar.

Indicadores SQL Server
En el siguiente gráfico podemos observar que no se presentaron bloqueos (Number of Deadlocks/sec), el máximo Número de bloqueos (Lock Waits/sec) por segundo fue de 1s. Total de (Full Scans/sec) 138. El Número máximo de transacciones en la base de datos corresponde a 1.524. Número máximo de conexiones a la base de datos 22.

Indicadores .NET CLR Memory y Loading

Porcentaje de uso de CPU que se lleva el recolector de basura CLR (% Time in GC). Se observa que el tiempo de procesamiento que le esta llevando al GC en recolectar la basura, está por encima de los umbrales propuestos por Microsoft. Los iconos amarillos corresponden a Umbrales sobrepasados de warning y los rojos a umbrales de error

El contador Current Assemblies, que nos indica el número total de assemblies en memoria se mantuvo en un valor constante, lo cual es normal.
Byte in all Heaps: Este contador es la suma de otros cuatro contadores: Gen 0 Heap Size, Gen 1 Heap Size, Gen 2 Heap Size y Large Object Heap Size. Muestra la cantidad de memoria virtual en bytes actualmente alocada en los heaps manejados. Si este contador crece sostenidamente indica que existe una leak de memoria en código manejado.

Configurando un WebTest y LoadTest en VS2008

1. Cuando realizas una grabación de tipo WEBTEST para tu aplicación, obtienes los Request y Response junto con sus respectivos parámetros POST y GET e información que viaja a través de estos. Como se muestra a continuación:

2. Transacciones: Cuando manejas formularios dinámicos en un mismo ASPX o página, en diferentes momentos dentro de la ejecución de tu aplicación, es importante bautizar y agrupar las URLS en transacciones, para que su posterior análisis sea más preciso. Como se muestra a continuación:

Bastara con indicar un nombre descriptivo como adicionando teléfono, o guardando datos del cliente, en el cual le indicaras la URL inicial Y la URL donde deseas que finalice la transacción

3. Reglas de Extracción: Alunos parámetros: Visual Studio Team test, los reconocerá automáticamente, otros no, sobre todo cuando se trata de aplicaciones muy dinámicas complejas. Y si tú aplicación es una de ellas tendrás que indicarle al Team test, tus propios patrones o reglas de extracción, de tal forma que la herramienta sepa exactamente qué información se alimentara dinámicamente, como IDS que usamos o pasamos por nuestros queryStrings que vienen de la base de datos, para poder hacer búsquedas o simplemente visualizar una grilla, o un detalle de una de uno de nuestros ASPX. Como se muestra a continuación:

La regla de extracción consistirá en indicarle, de nuestro reuest/response que la información va a ser dinámica, para este ejemplo el valor que aparece en negrilla:name="h_idCase" value="454“>

Posteriormente el editor gráfico nos dejara, reutilizar esta variables a mediantes combos o escribiendo directamente el nombre de nuestro parámetro dentro de los caracteres {{}}

4. Como preparar nuestra prueba de carga?

Bautizar nuestra prueba de carga:

Distribución de usuarios (Total 50 y como se van a ir incrementando):

Pruebas de carga a adicionar, en este caso 1, pero se pueden adicionar varias en paralelo:

Distribución en términos porcentuales de navegadores a emular, en este caso 100 % para IE:

Distribución en términos porcentuales de las redes a emular (se pueden las más optimas canales T1, para nuestro caso LAN):

Registro de servidores de contadores a analizar, para el ejemplo se adicionaron dos servidores, los cuales veremos más adelante en los reportes (Proximo POST)

Tiempo de calentamiento de nuestra aplicación, este no se tiene en cuenta para la estadística

Ejecutar prueba de carga.