Visión General de las Pruebas de Rendimiento (I)

Con frecuencia escuchamos el término pruebas de rendimiento, e inmediatamente se viene a nuestra cabeza el hecho de hacer pruebas a una aplicación web.

  El termino de pruebas de rendimiento (performance, prestaciones, etc, etc) muchas veces es tomado de forma errónea por diferentes profesionales de las empresas que se dedican al desarrollo de software, incluso por los que nos dedicamos a hacer pruebas de rendimiento.

  Una prueba de rendimiento evalúa el comportamiento de un sistema completo o cualquiera de sus elementos (back-end, front, middle-ware) conforme a un requerimiento especifico. Esto generalmente es posible, mediante una herramienta de prueba automática, capaz de simular un gran número de acciones simultaneas que nos permita llegar a tal objetivo.

  Lo que he considerado el punto clave en la concepción de este tipo de pruebas, es que las tareas comiencen desde el inicio de desarrollo del sistema, y aún más importante saber cual es el modelo de uso del mismo. Por modelo de uso, me refiero a saber cuales son las características más usadas del sistema (o las acciones que más importancia e impacto tienen, si estamos hablando de una aplicación web). También habría que considerar todas las capas que involucran las pruebas, para que en momento dado, sepamos donde situar los problemas que puedan resultar.

 
 Los modelos de uso nos darán la pauta para plantear los objetivos, que mas adelante cuando estemos listos para realizar las pruebas, tendrán que alcanzarse y lograr su cumplimiento.

Continuará...

Ancho de banda disponible en Cloud Testing

1 Ancho de banda en Cloud Testing

Durante las pruebas de rendimiento de un sistema es importante asegurarnos que no existe ningún elemento ajeno a la aplicación que pueda actuar como limitador de la inyección de carga. La capacidad de los inyectores de carga y el ancho de banda disponible deben ser elementos que debemos tener controlados durante un proceso de pruebas de rendimiento. En esta entrada nos centraremos en los problemas asociados al ancho de banda y a la lantencia. 

En un entorno clásico de pruebas (hosting), los inyectores de carga se sitúan "lo más cercanos" posible a los servidores de la aplicación bajo pruebas. Esto permite disponer de un ancho de banda próximo al de la red corporativa y que las peticiones que realicen "pasen" por un número mínimo de elementos de red (routers, hubs, switches, etc...). 

En la actualidad, el crecimiento de entornos Cloud, y la necesidad de utilizar técnicas Cloud Testing para realizar las pruebas de rendimiento impide que tengamos controlado el ancho de banda del que disponemos. Los inyectores de carga en un entorno Cloud Testing se encuentran distribuidos en situaciones geográficas alejadas de los servidores, de forma que la red puede influir negativamente en nuestras pruebas.

2 La red como cuello de botella

Después de realizar una prueba de rendimiento podemos encontrarnos un punto de saturación que no corresponda con la saturación de otros elementos en la plataforma de la aplicación: CPU de los servidores, memoria, etc...

Cuando se produce esto, es necesario que nos tomemos un tiempo en comprobar el ancho de banda del cual disponemos para asegurarnos que la red no es un cuello de botella.

El Test de ancho de banda es aplicable a entornos de pruebas clásicos donde los inyectores se encuentran dentro de la red corporativa, pero es extremadamente necesaria realizarla cuando las pruebas de rendimiento se realizan sobre entornos de Cloud Testing, ya que en ese caso la red no es un elemento que podamos controlar, y es necesario seleccionar aquellos inyectores de carga en una situación geográfica adecuada.


3 Test de ancho de banda 

Los problemas asociados a la red en las pruebas de carga no son fáciles de desenmascarar. De hecho, demostrar que la red es un cuello de botella para nuestras pruebas de carga es una tarea complicada. En cambio, demostrar la red NO es el problema, es una tarea relativamente sencilla.

El Test consiste básicamente en realizar una prueba de carga contra una URL de nuestra aplicación controlando el tamaño de la misma y las carácterísticas. Nuestros scripts y nuestra herramienta de pruebas la debemos configurar adecuadamente:

• La URL debe hacer referencia a un elemento estático de nuestra aplicación. No es conveniente seleccionar peticiones que implique a la capa lógica de la aplicación.
• El tamaño del elemento estático no debe ser excesivamente pequeño. Un tamaño entre 50 y 500 Kbytes es suficiente. En otro caso nuestra en prueba podría verse afectada por la propia latencia de red.
• Debemos seleccionar peticiones que implique elementos "non-compressible" y que en las cabeceras de la  petición aparezca explicitamente la opción "non-compressed". De esa forma garantizamos que los servidores no comprimirán el elemento que estamos pidiendo en el test.
• Debemos usar peticiones persistentes. Forzar a que se abra una nueva conexión en cada petición añade una mayor latencia.
• No utilizar peticiones SSL. La encriptación es un procedimiento costoso y añade un mayor tiempo de respuesta.
• No utilizar la simulación de caché de los navegadores durante la prueba. En caso contrario la petición no recibirá el tamaño completo del elemento, tan solo la confirmación de que el elemento no ha cambiado y que se encuentra cacheado (HTTP code 304).
• Realizar la prueba seleccionando varios inyectores de carga. Idealmente intentaríamos realizar el test de ancho de banda con los mimos inyectores que en la prueba de carga de nuestra prueba.
• Utilizar un número de Usuarios Virtuales relativamente elevado (superior a 10).

Una buena solución es seleccionar para la prueba un elemento ya comprimido y de tamaño medio. Por ejemplo elementos con extensión *.gif, *.mp3, etc... A modo de ejemplo se muetra una petición de URL en la sintáxis de LoadRunner:

    web_url("icoazul.gif",
        "URL=http://servidor:puerto/base/img/icoazul.gif",
        "Resource=1",
        "RecContentType=image/gif",
        "Referer=http://servidor:puerto/base/frameabajo",
        LAST);

Con estas condiciones realizaremos una prueba de carga y observaremos los resultados del througput (Bytes/s) que obtenemos durante ella. 

Si el througputh alcanzado en el test de ancho de banda es superior al alcanzado en la prueba de rendimiento contra la aplicación, debemos descartar que la red no puede ser un cuello de botella, y que por lo tanto debe existir otro elemento que limite el rendimiento de nuestra aplicación.

En el caso de el througputh sea similar en el test de ancho de banda y en la prueba de rendimiento, cabe la posibilidad de que hayamos saturado la capacidad de inyección de los inyectores. En ese caso debemos repetir el test pero seleccionando un número mayor de inyectores. Si doblamos el número de inyectores, el throughput debe incrementarse en la misma proporción. Si por el contrario el throughput se mantiene en los mismos valores, debemos valorar la posibilidad de que la red sea un cuello de botella en nuestra capacidad de inyección.

JMeter(I). Primeros Pasos

Jmeter (I). Primeros pasos

En esta serie de artículos, vamos a tratar sobre una de las herramientas más populares que se encuentran disponibles en la actualidad para las pruebas de carga. Las razones que la avalan son su disponibilidad, su amplio uso por la comunidad de técnicos y su flexibilidad.

Un poco de biografia.

Un breve vistazo a la página oficial (http://jakarta.apache.org/jmeter/index.html) nos cuenta que JMeter es una aplicación de código libre, basada en el lenguaje 100% compatible Java , diseñada para pruebas funcionales y medición de rendimiento. Inicialmente se usaba únicamente para pruebas de aplicaciones web, pero se ha extendido a otros entornos.

Soporta entre otros, los siguientes protocolos

· Web - HTTP, HTTPS

· SOAP

· Database via JDBC

· LDAP

· JMS

· Mail - POP3(S) and IMAP(S)

Asimismo, permite la inclusión de código ejecutable creado por el usuario basado en diferentes lenguajes de scripting a través de un módulo llamado Beanshell scripting. Esto permite realizar determinadas tareas en las pruebas, como validación de respuestas específicas, creación de flujos de control dependiendo de las respuestas recibidas, correlación…etc. Sin embargo, no es una tarea simple y su uso requiere de conocimientos avanzados de programación en los lenguajes de scripting y su adaptación al módulo de JMeter.

Instalación

La instalación de la herramienta es muy sencilla. Básicamente requiere de dos cosas

· En entorno de ejecución Java (JRE), que se puede obtener de http://java.sun.com

· El binario distribuido por la web disponible en (http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi)

· También se encuentra disponible el fuente de la aplicación, para compilarlo directamente en el equipo o, si uno tiene la capacidad y las ganas, realizarle modificaciones de acuerdo a la licencia GNU.

Es conveniente incluir las siguientes variables en el sistema

• JAVA_HOME ;Indicando la ruta de instalación definida para la JRE.

• JAVA_BIN ; Indicando la ruta JAVA_HOME/bin, para indicarle el binario.También se puede incluir en la variable de entorno PATH

• JAVA_LIB ; Indicando la ruta JAVA_HOME/lib, para incluir las librerias

Las últimas versiones del JRE (al menos bajo Windows), crean este tipo de variables y actualizan el entorno para que sea transparente al usuario

Grabación de navegaciones

Como otras herramientas, el concepto de ciclo de navegación está presente en JMeter. Básicamente trataremos de reproducir la secuencia de navegación deseada, capturando las peticiones HTTP lanzadas por un navegador, modificándolas para parametrizarlas y tratar sus respuestas para comprobar su validez o reutilizarlas en peticiones siguientes.

Aunque la herramienta permite crear peticiones de manera directa, tecleando directamente la secuencia de URLs a probar, lo más común es utilizar un navegador y capturar dicha respuesta. Para ello utilizaremos dos elementos de JMeter:

· El Banco de Trabajo

· El plan de pruebas

El Banco de trabajo podemos considerarlo como la parte de configuración y grabación online de las navegaciones. Un detalle MUY IMPORTANTE es que lo que se añade a este elemento NO SE GRABA, estando sólo disponible mientras si se mantenga la instancia de JMeter abierta

El Plan de Pruebas podemos considerarlo como una mezcla entre “script” que reproduce la navegación y el escenario que los ejecuta.

Es muy útil hacer una planificación previa sobre lo que se va a grabar, dividiéndolo en pasos o subtransacciones, de manera que tengamos claro a qué paso pertenece cada petición. Esto nos permitirá no sólo tener un flujo de control sobre la navegación, sino que permitirá realizar mantenimientos sobre el script de manera más sencilla . Hemos creado sobre un Thread Group/Grupo de Hilos Dos controladores de transacción (T0_Login y T1_Logout)

Primeros pasos de grabación

Como paso necesario para la captura de la navegación de un usuario a través de un navegador, debemos incluir un servidor Proxy http en el banco de trabajo.

El servidor Proxy es lo que se da en llamar un “Elemento No de Prueba”, que son las diferentes opciones que se pueden incluir sólo el banco de trabajo. Este elemento funciona como un Proxy /capturador de tráfico, que escuchará todo el flujo http que pase por el puerto configurado en sus opciones

Aquí se indica en qué puerto TCP estará escuchando. Se incluirá en la configuración de Proxy del navegador a usar como cliente para la navegación	En esta “rama” del plan de pruebas se graban y agrupan las peticiones correspondientes al paso	Indicamos elementos a excluir de la grabación, esto permite evitar llamadas a elementos estáticos (imágenes, textos..etc). Se pueden definir patrones de elementos a grabar/excluir siguiendo el formato de reglas usado por Perl para expresiones regulares.
Podemos especificar qué contenido queremos incluir/excluir explícitamente	Podemos indicar que no grabe peticiones fuera de dominio de prueba	A priori, es mejor dejar por defecto esta sección

Una vez que configuremos el navegador, pulsaremos en la pantalla del Servidor Proxy http el botón , con lo que empezará a grabar las solicitudes que le lleguen.

El procedimiento sobre el que hacemos hincapié es grabar cada paso, seleccionando en el controlador objetivo la transacción correspondiente. Pueden incluso añadirse subtransacciones de la transacción marcándolas como hijas de la que cuelgan

El resultado de la grabación de la actividad del navegador, será reflejada como una estructura en árbol de peticiones HTTP , como la que se observa en la siguiente imagen.

Ilustración 1. Resultado de la grabación de un ciclo simple de navegación

En este caso, podemos ver como una petición http de tipo GET sobre la URL https://www.prueba.es refleja el acto de la pulsación el botón “Aceptar”,junto con algunos parámetros .

En este caso, el campo “Nombre” y “Comentarios” son de texto libre y pueden ser usados para una descripción textual del paso (si procede)

El campo “Path”, refleja el camino relativo al dominio www.prueba.es, junto con determinados parámetros incluidos en la llamada.

Este script puede ser salvado con las opciones del menú típicas de cualquier entorno gráfico de ventanas y posteriormente ejecutado para ser depurado, incluyéndole modificaciones para variar su comportamiento según la respuesta y salvar sus resultados en un fichero para su análisis posterior.

Continuará….

Problemas más comunes en las pruebas de carga

Problemas más comunes en pruebas de carga

El artículo que incluimos a continuación pretende ser un muestrario de las dificultades comunes que se presentan en el día a día del técnico de pruebas. Un auténtico experto, adquiere la experiencia a la hora de resolverlos con métodos que van desde la investigación exhaustiva , el método “prueba y error” y suficiente suerte como para saltar la banca de un casino…

Pasemos a una breve descripción del artículo.

1. Definición de objetivos.
2. Modelado de comportamiento del usuario
3. Generación de la carga
4. Monitorización estado
5. Análisis de resultados

Definición de objetivos

Habitualmente cuando, se pretende realizar una prueba de carga, los objetivos a alcanzar son difíciles de detallar. Salvo que los peticionarios tengan experiencia previa en este tipo de pruebas, siempre hay que realizar una pequeña presentación o “bienvenida” a este mundillo.

Sólo hay una excepción a esta regla y son las pruebas a lanzar cuando se presenta un problema en la explotación. En ese caso, se tienen claros los objetivos:

• Reproducir el fallo
• Detectar sus causas
• Una vez pasado por Desarrollo, comprobar que se corrige dicho fallo

El solicitante habitual debe comprender que las pruebas de carga consiguen dar una idea del rendimiento de la aplicación en concurrencia, detectan posibles problemas debido al consumo de los recursos, los posibles cuellos de botella.

El modelado de las navegaciones

Es preciso determinar cúales son las actividades de los usuarios o procesos propios de la aplicación que causan los problemas. En una aplicación en explotación siempre se puede recurrir a los log de actividad de la misma (los de acceso web, uso de la BBDD, monitorización de seguridad) y, una vez tratados, determinar cúales son los posibles “caminos críticos” que generan el fallo –en el caso de ser ese el propósito de las pruebas- o determinar el rendimiento de la aplicación (ya sea real, para comparar con nuevas versiones o extrapolar para los posibles crecimientos de actividad)

Generación de la carga

Una vez definidos los ciclos de prueba, hay que saber cómo incrementar la carga para alcanzar el objetivo determinado.

Aunque, habitualmente las pruebas estresantes son las más comunes, hay pruebas que pueden ser más ajustadas a la realidad. Algunos ejemplos son estos

• Pruebas con escalonamientos de carga mínimos. Este tipo de pruebas sirven para confirmar problemas de serialización de peticiones. Es decir, podemos detectar que se está produciendo una situación en la que un recurso usado por el sistema es usado sin paralelización, bien sea por configuración del servidor (tamaño de la cola de petición , RqThrottle, número de conexiones activas simultáneas de JRun…), bien por código -clases obsoletas de Java, estructuras de control poco eficientes –

• Pruebas de aislamiento. En estas pruebas, se selecciona una llamada específica que se produce durante la navegación del usuario, pero que es la que puede causar más problemas. De esta manera, en entornos más reducidos que el de Explotación, se puede conseguir reproducir una situación de estrés de recursos que pueden ser “apantallados” por la poca capacidad de las capas de presentación (por ejemplo, un problema en BBDD que no se pueda reproducir debido a que el frontend web agota recursos de manera que no llega a generar el nivel de carga necesario para que se presente)

• Pruebas de estabilidad. Consisten en mantener la carga durante largos periodos de tiempo, de manera que la degradación del uso se manifieste en la aparición de los problemas. Aunque actualmente, con los reinicios programados de los servidores estas pruebas tienen más sentido como medida preventiva.

• Pruebas de impacto. Simulan el uso concurrente masivo de una aplicación en un breve periodo de tiempo. Por ejemplo, el inicio de la jornada laboral en unas oficinas donde utilicen una herramienta corporativa común, como una intranet, o las consultas de determinados periodos (nóminas, facturas del mes, declaraciones de Hacienda, reservas de viajes…).

• Pruebas de tolerancia a fallos. Se busca verificar tanto la capacidad de mantener el servicio de la aplicación, como detectar los cuellos de botella de la infraestructura. Este sería el caso de aplicaciones con entornos de alta disponibilidad ,que incluyan balanceado de aplicaciones, servidores de contingencia, duplicidad de centros de proceso de datos…

Monitorización de estado

La arquitectura usada por la aplicación o definida para el entorno determinará los elementos a monitorizar e incluso las herramientas para ello.

Podemos diferenciar entre monitorizaciones intrusivas y no intrusivas, si usamos una aplicación específica como Introscope , Diagnostics, JTrace …que incluyen clases que ejecutan rutinas de temporalización –o instrumentalizadas- que se incluyen en el arranque de los servidores. Su ejecución afecta y puede que decisivamente, al rendimiento de las aplicaciones, al compartir directamente recursos con ellas

Las monitorizaciones no intrusivas, utilizan comandos del sistema operativo o análisis a posteriori de logs de sistema, de manera que los comandos no utilicen directamente los mismos recursos que las aplicaciones.

También hay elementos de la arquitectura que requieren monitorizaciones que no suelen estar al alcance de los conocimientos de los técnicos de pruebas. Por ejemplo, los entornos que tienen parte de sus elementos basados en plataformas tipo OS/Z o Legacy, requieren de personal muy especializado para analizar y comprender la información que estos sistemas generan

Otro caso específico es el de la infraestructura de comunicaciones. Esta puede ser bastante compleja y requerir de un conocimiento profundo de la misma y de los conceptos que maneja (encaminamiento, pérdidas de paquetes, TTL, número de colisiones…etc)

Análisis de resultados

Aquí se establece la verdadera parte “artesanal” del proceso de pruebas de carga. Al poder considerarlo como un proceso que se retroalimenta, los análisis pueden mostrar a veces lo que nos hemos marcado como objetivo de las pruebas.

En esta parte además, la experiencia previa con aplicaciones con elementos comunes, ya sea de arquitectura o por los productos utilizados por la misma nos puede servir de guía…o de distracción.

Aunque es cierto que se reproducen de manera contínua errores bien sea en el manejo de los productos (configuración, desconocimiento de particularidades de codificación, inexperiencia.) o en el planteamiento de la aplicación (uso indebido de variables, estructuras de control inadecuadas, adecuación incorrecta al flujo de negocio…), no debemos guiarnos por prejuicios, aunque tengan su base.

El proceso de análisis debe ser objetivo y basado en la observación crítica de los resultados, solicitando ayuda para solventar las lagunas en el conocimiento de las monitorizaciones o comportamientos de los sistemas o servidores que nos haga falta.

Automatización de Pruebas: Creencias Erroneas

1  La Automatización de Pruebas

Dentro del Testing de Software, la automatización de pruebas es una de las actividades que presentan una mayor expectativa. La posibilidad de ejecutar las pruebas de software de manera desatendida, hace que las organizaciones vuelquen sus esperanzas en la automatización como la solución ideal para abaratar los costes y acortar los tiempos de pruebas.

2  Creencias erróneas sobre la Automatización.

Las esperanzas puestas en la Automatización de Pruebas se deben generalmente a puntos de partida erróneos, que hacen que se espere de ella expectativas que no proporcionarán:

• Error 1: La automatización de pruebas es una actividad fácil de poner en marcha.

La automatización de pruebas no es una actividad fácil de implementar. Necesita de una herramienta de automatización que soporte las diferentes tecnologías, personal con conocimientos, una metodología de trabajo adecuada y de recursos hardware.

• Error 2: Los casos automáticos  se ejecutan más rápido que de forma manual.

Los casos automatizados no se ejecutan más rápidamente que de manera manual. La ejecución de un mismo caso de prueba puede ocupar mayor tiempo que de manera automática. Esto no significa un menor rendimiento ya que el verdadero potencial de la automatización se encuentra en que la ejecución de casos se realiza de manera desatendida, con disponibilidad 24x7, se ejecuta de manera paralela a las actividades manuales y permite destinar el tiempo manual de pruebas a tareas de mayor valor (pruebas de evolutivos, pruebas no funcionales, etc...)

• Error 3: La automatización de pruebas es una “grabación” de pasos en un script.

Automatizar un caso de prueba no es únicamente "grabar". Un caso de prueba automatizado debe ser robusto y fiable. Para ello es necesario introducir en los casos de prueba elementos de control como son: validaciones de correcto funcionamiento, control de flujo y sentencias de reporting que prolongan el tiempo de construcción de los casos de prueba.

• Error 4: Empezar a automatizar en fases tempranas del desarrollo de la aplicación.

La automatización se debe llevar a cabo una vez que las funcionalidades de nuestra aplicación se encuentran estables e implementadas de una manera definitiva. Comenzar a automatizar antes, significaría que nuestros casos automáticos cambien de manera continua, provocando constantes fallos en la automatización y requiriendo destinar tiempo al mantenimiento de los scripts.

• Error 5: Todos los casos de prueba son automatizables.

No es posible automatizar cualquier caso de prueba. Casos de prueba que requieran actuaciones manuales o tomas de decisión complejas no son automatizables.

• Error 6: Buscar rentabilidad a corto plazo.

La automatización es una inversión a medio plazo. A corto plazo significa una inversión en creación de un “parque” de casos de prueba, en herramientas, y en la infraestructura que soporte las tareas asociadas a la automatización.

• Error 7: Automatizar casos con corta “esperanza de vida”

No se deben automatizar casos de prueba cuyo número de reejeuciones va a ser pequeño. La automatización de un caso de prueba comienza a ser rentable cuando el tiempo destinado a la automatización, es inferior al tiempo ahorrado en ejecutar ese caso de manera manual.

• Error 8: Los casos automáticos detectan más “bugs”.

La automatización de un caso de prueba no detecta errores. Es la definición del caso de prueba el que permite la detección de errores o defectos, es decir, que el mero hecho de automatizar un caso no significa que se vayan a detectar más errores de los que se detectarían ejecutándolo de manera manual.

Monitorización de recursos en las Pruebas de Rendimiento.

1  Consumo de Recursos.

En las Pruebas de Rendimiento se busca estresar una aplicación introduciendo concurrencia y simulando el comportamiento que tendrán los usuarios reales una vez que el sistema esté en producción. Los límites de funcionamiento de la plataforma quedarán delimitados por la saturación de uno o varios elementos.

Durante la fase ejecución de las pruebas es indispensable tener controlado el consumo en los distintos elementos que componen la arquitectura de nuestro sistema. Su estudio, permitirá detectar el cuello de botella, encontrar la causa de los posibles fallos y optimizar las prestaciones de la aplicación.

2  Principales indicadores

• Consumo de CPU

Indica el tiempo de procesador dedicado a la aplicación. En las arquitecturas unix y Windows este indicador se expresa en términos de porcentaje de uso (%), por lo que valores próximos a 100% indican una saturación de este recurso.

En aquellos servidores compartidos por varias aplicaciones será necesario “filtrar” por la aplicación que estamos probando para identificar el consumo asociado a nuestra aplicación.

• Memoria:

La evolución de la memoria en los servidores permite detectar problemas asociados al agotamiento de los mismos. Los “memory leak” es el problema más común y está asociado a la no liberación de bloques de memoria después de su uso.

• Disco:

Una excesiva utilización del sistema de disco puede penalizar el rendimiento. Los procesos de escritura y lectura son costosos en tiempo. Si la escritura está asociada a procesos de swap pueden deberse también a agotamientos de memoria.

• Average Load/ Runnable Queue

Ambos indicadores muestran información del número de proceso o hilos que han sido bloqueados en un periodo de tiempo y que se encuentran a la espera de poder utilizar un recurso. Un Average Load alto no implica directamente un consumo de CPU elevado.

Un Average Load mayor a cuatro veces el número de procesadores disponible es un indicador de saturación en algún recurso.

• Número de conexiones TCP:

El mantenimiento de conexiones abiertas puede indicar una mala gestión de las conexiones. El aumento continuo de las conexiones en estado TIME_WAIT o CLOSE_WAIT puede indicarnos que las conexiones no se están reutilizando adecuadamente.

• Ancho de banda:

Generalmente el agotamiento en el ancho de banda no está asociado a problemas en la aplicación. Conviene revisar el ancho de banda disponible durante las pruebas y que puede ser utilizado ya que puede ser un factor limitante para la inyección de carga.

Elementos de red (routers, switches, hubs, etc… ) pueden limitar la capacidad para aceptar carga del sistema.

3  Herramientas de monitorización.

• Monitor de rendimiento de Windows.

• Comandos del Shell de UNIX:

Unix dispone de comandos específicos que proporcionan el estado de los distintos recursos. Algunos comandos son: sar, vmstat, netstat, ps, etc..

• Herramientas Open Source: Existen diferentes herramientas Open Source que permiten integrar sistemas de monitorización:
• Nagios
• Hyperic
• Zabbix 

• Herramientas Comerciales: la mayoría de las herramientas de Performance Testing permiten integrar la monitorización del consumo de recursos conjuntamente con la prueba. Productos como LoadRunner de HP, SilkPerformer de Borland, o IBM Rational Performance Tester disponen de herramientas que permiten la monitorización On Line de los recursos de manera integrada con los resultados de nuestra prueba.

Pruebas de Rendimiento. Concurrencia.

concurrencia. (De concurrente).
 1. f. Acción y efecto de concurrir.

 2. f. Conjunto de personas que asisten a un acto o reunión.

 3. f. Coincidencia, concurso simultáneo de varias circunstancias.

 4. f. Asistencia, participación.

(Diccionario de la Lengua Española. R.A.E)

1 Uso concurrente de una aplicación.

En el ámbito de las pruebas de rendimiento son muy comunes los términos "concurrencia" y "simultaneidad". Ambas se utilizan indistintamente para dar información sobre el uso o la demanda que en un momento determinado está soportando una aplicación. Sin embargo, el concepto aparece con ciertas ambigüedades ya que por concurrencia podemos referirnos indistintamente al número de usuarios o a la demanda de operaciones atendidas (con independencia del número de usuarios). Tampoco aclara el intervalo en el que se ha medido la simultaneidad (minuto, hora, día..)

Para que las prueba de rendimiento cumplan su objetivo, es necesario diseñarlas intentando reproducir los niveles de demanda que la aplicación tendrá en la realidad. El comportamiento de la aplicación, incluido el tiempo de respuesta que perciben los usuarios, dependerá de la concurrencia que exista en un momento determinado sobre la aplicación. Por ello debemos fijar unos criterios que permitan definir con exactitud que entendemos por "concurrencia" en las pruebas de rendimiento.

2 Tipos de Concurrencia

• Concurrencia a Nivel de Aplicación: Nos indica el número de usuarios que se encuentran en la aplicación en un instante dado.

• Concurrencia a Nivel de Proceso de Negocio: Es el número de Operaciones de Negocio de un determinado tipo que se realizan en un determinado periodo de tiempo.

• Concurrencia a Nivel de Transacción: Indica el número de operaciones que se realizan de manera simultanea (en el mismo instante).

3 El diseño de las pruebas de rendimiento.

La información que aporta la concurrencia a nivel de aplicación no es suficiente para el diseño realista de pruebas de carga o rendimiento. El número de usuarios que en un instante están conectados a la aplicación no implica directamente una mayor demanda de operaciones, ya que no implica que se encuentren operando todos. Por otro lado, las operaciones que realizan los usuarios no conllevan el mismo consumo de recursos en los servidores, ya que existen funcionalidades más pesadas o que penalizan de manera más alta el rendimiento

Para el diseño efectivo de una pruebas de rendimiento que nos permitan validar que la aplicación va a soportar la demanda esperada en producción es necesario partir de datos de concurrencia a nivel de operación o consumo en los recursos. Algunos datos que podemos utilizar son:

• Número de operaciones por intervalo (hora, minuto, segundo, etc...).
• Pico máximo de operaciones realizadas en un momento dado.
• Throughput: Bytes/segundo, Paginas/segundo, Hits/segundo
• Conexiones físicas en los diferentes elementos de la plataforma: Balanceadores, Servidores, Base de Datos,...

Respecto al intervalo temporal, debemos partir de datos que representen la demanda real, tomar el dato de operaciones medio en un día puede llevar a infravalorar la carga que realmente va a soportar una aplicación ya que esta no se encuentra distribuida uniformemente. Por esa razón conviene dar las medidas en intervalos temporales más pequeños y que consideren los picos de momentos puntuales: Operaciones/hora, Operaciones/Minuto, etc..

No obstante, aunque el grueso de las pruebas de rendimiento las diseñemos a partir de datos operacionales, si nos es posible, debemos planificar al menos una prueba que introduzca en la aplicación un número elevado de usuarios. Aunque estos usuarios trabajen a un nivel  bajo conviene comprobar que los diferentes elementos de la plataforma funcionan correctamente, ya que el mero hecho de establecer una sesión tras un login tiene asociado un consumo de memoria en los servidores.