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.
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.
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.
No hay comentarios:
Publicar un comentario