miércoles, 23 de noviembre de 2011
martes, 22 de noviembre de 2011
Mejores Practicas Rendimiento (Top10)
- Utilizar diferentes identificadores de sesión.
- Utilizar datos dinámicos en las operaciones que se vayan a realizar.
- Para las aplicaciones que acarrean datos, se deberán parametrizar estos datos.
- Hacer escenarios mixtos, ponderando las funcionalidades o ciclos utilizados de acuerdo a su prioridad o nivel de impacto en el negocio, pero siempre utilizar diversos ciclos.
- Hacer pruebas de estrés independientes a los elementos (ciclos, middleware, base de datos, servicios, etc.) que puedan sean susceptibles a ser un cuello de botella, para comprobar su comportamiento individual.
- No sobrecargar los equipos desde los cuales se está generando la carga, esto puede distorsionar los resultados y hacerlos poco fiables.
- Siempre en cada ejecución tener las mismas condiciones de ejecución (Entorno, Recursos, Generadores de Carga.)
- Introducir y Finalizar la carga gradualmente, para evitar comportamientos abruptos del sistema.
- Identificar los criterios de aceptación de rendimiento y evaluarlos según el resultado de la prueba.
- Validación exhaustiva de las peticiones que se lanzan, para no provocar resultados incoherentes.
lunes, 21 de noviembre de 2011
Criterios de Aceptación de Rendimiento
La aceptación de un sistema forma parte del ciclo de vida del mismo y uno de los principales puntos a tomar en cuenta durante la aceptación, es el resultado de las pruebas realizadas al mismo, entre estas pruebas están las pruebas de rendimiento, las pruebas de carga y las pruebas de estrés cada una de estas permite determinar como se comportará el sistema bajo determinadas condiciones y si este comportamiento satisface los objetivos iniciales y por supuesto satisface al usuario.
En cuanto a las pruebas de rendimiento su éxito generalmente se mide en función de los tiempos de respuesta, los recursos que consume, pero para poder realizar esto al mismo tiempo se necesita un punto de comparación que nos permita armar un checklist de aceptación para poder realizar nuestra evaluación.
Esto es el punto de partida que permitirá medir el éxito del sistema desarrollado, basado en las pruebas de rendimiento, por lo tanto el checklist debe ser creado en función de los estándares y especificaciones de la industria y en otros sistemas que usen el mismo criterio para medir el rendimiento.
Muchas veces las partes interesadas por parte del cliente no basan sus requerimientos en estándares sino que plantean requisitos como que la aplicación solo puede estar no disponible 5 minutos en el transcurso de un año o tiempos de respuesta que no se acercan de ninguna manera a la realidad de la industria, es aquí cuando debemos con habilidad captar la intención del cliente por ejemplo preguntándole como espera el que el sistema responda en función de otros sistemas similares existentes, o como que otro sistema similar le gustaría que respondiera y en el caso de que responda con porcentajes o métricas en segundos deberíamos preguntarle porque ha escogido ese valor y en que se ha basado para ello.
La idea es realizar preguntas que no tengan respuestas cuantificables y de allí pasar a preguntas que nos permitan transformar las primeras preguntas en métricas cuantificables realistas que reflejen la intención del cliente.
miércoles, 16 de noviembre de 2011
JMeter (VI): Utilidades externas y algunos consejos.
Para finalizar este pequeño tutorial, vamos a indicar una serie de listener y elementos añadidos publicados por algunos usuarios de JMeter que han tenido a bien compartir con los menos habilidosos de los mortales.
Instalación
La instalación de los plug-in disponibles es muy sencilla .Básicamente consiste en descomprimir el fichero obtenido en http://code.google.com/p/jmeter-plugins/ en la carpeta lib/ext de la instalación de JMeter y reiniciar el mismo.
Listener “pata negra”
Entre los listener que obtendremos, los que más utilidad presentan son
- Active threads count
- Througput bytes
- Transacciones fallidas vs correctas
 |  |  |
Ilustración 1. Listener active threads,througput y trasacaciones correctas/fallidas
Todos estos listener consumen bastantes recursos en activo. Sobre todo si se usa el entorno gráfico de JMeter. Es por lo tanto no ya recomendable sino casi de obligado cumplimiento que pruebas de carga con elevada concurrencia, sean lanzadas mediante la línea de comandos salvando a fichero las salidas de estos listener.
Posteriormente, se pueden usar los ficheros obtenidos bien como entrada a macros de generación de gráficas propias o para generar las incluidas en el plugin. Para ello, sencillamente hay que recordar que los listener (todos, no sólo los incluidos en el plugin) )usan como salida en ejecución el nombre del fichero que le indiquemos en la casilla de “Escribir datos a archivo”, usándola como entrada cuando esta detenido.
Ilustración 2. Entrada y salida a fichero para listener
Seleccionando el botón de “Navegar” permite seleccionar un fichero ya salvado y tomarlo como entrada para mostrar las gráficas a posteriori.
Lógicamente deben coincidir el tipo de listener que generó el fichero y el que lo usa, así como la configuración de datos salvados que usen ambos
|
Configuración listener
Los listener de los plugin tienen como características comunes un tiempo de muestreo. Es conveniente ponerle un intervalo de muestreo adaptado a la duración total de la prueba, ya que los valores por defecto son de 500 -1000 milisegundos
Ilustración 3. Configuración intervalo muestreo listener plugin
Otros elementos interesantes a tener en cuenta (en los listener en que aplique) son las opciones de
- “Detailed Display”,para que dibuje todas las peticiones y controladores de transacción
- “Aggregated display”: para que realice la consolidación de todas las muestras en una sola.
Ilustración 4. Configuración listener: Visualización detallada / general
Uso e interpretación
El listener de Active threads count muestra la evolución de la carga, presentando en la gráfica los hilos de ejecución activos a lo largo de la prueba ,así como su escalonamiento.
La gráfica presentada por el listener de Througput bytes, nos muestra el ancho de banda consumido en la respuesta del servidor. Junto con el listener de los hilos activos y las transacciones, permite indicar tanto si se ha alcanzado el punto de saturación de la prueba, como detectar si la red es un cuello de botella.
La relación de transacciones correctas/fallidas también nos permite señalar a partir de qué momento se puede determinar que la inyección de carga causa fallos en la aplicación probada o para dar por válida una prueba, si la tasa de error es limitada.
Consejos útiles
Es útil disponer de un visualizador de aserciones de manera que se detecten aquellas que dan error. Si además, incluimos los datos que se están usando en esa petición, códigos de respuesta del servidor o mensajes de fallo que sepamos puedan suceder, esto mejorará el proceso de pruebas al detectar los fallos de manera más entendible. Al igual que lo comentado para los listener, se puede usar la opción de “Escritura a fichero” como método para salvar las respuestas y posteriormente ,cargarlas en el visualizador
En el caso de usar el visualizador de aserciones, las opciones a configurar dentro de la escritura de fichero, se pueden reducir, no siendo necesario salvar, ni el tamaño de respuesta, ni el tiempo de la misma. Y es útil activar la opción de “salvar como XML” para visualizar la aserción de manera más comprensible, aunque incrementa notablemente el tamaño del fichero obtenido.
El uso del planificador de tareas de los grupos de hilos (Threads groups), en el caso de ser lanzado por línea de comandos , podría tener el inconveniente de no coincidir el inicio de la ejecución con la hora del planificador de tareas del sistema operativo
Una solución a este inconveniente es indicar valores ,formalmente correctos, pero inexistentes a la hora de ejecución,tal y como vemos en la pantalla de configuración del grupo de hilos
Ilustración 5. Parámetros fantasma en el planificador para ejecución inmediata
De este modo, podemos indicar una duración específica del grupo de hilos/plan de pruebas ,en lugar que tenerlo que definir por un contador de iteraciones
Una buena práctica, para el mantenimiento de ciclos dentro de un plan de prueba consiste en crear un “esqueleto” de escenario en el que se incluyan los listener generales del plan de pruebas, los escritores de datos simples y visualizadores de aserciones fallidas y mezclar sobre dicho fichero los de los ciclos individuales.
Ilustración 6.Menú mezcla
Truco desde la experiencia: el fichero XML que contiene el plan de pruebas de JMeter, puede ser tratado desde un editor de textos. Esto nos permite realizar tareas repetitivas buscando patrones y tratarlos, de manera que no tengamos que estar editando punto por punto todo el fichero desde el entorno gráfico.
|
Epílogo
Llegados a este punto, hemos logrado describir todos los conocimientos básicos para el uso de JMeter como herramienta de pruebas de carga. Al menos, esperamos haber conseguido solventar las dudas que genera la documentación que acompaña a la herramienta por defecto. No obstante, como tutorial notablemente incompleto que es, espero que el lector sea indulgente y juzgue comparando con los trabajos de documentación que se pueden encontrar en español por Internet.
Como fuentes, mi reconocimiento a los blogs
Y como elemento de utilidad, el evaluador de expresiones regulares on-line de JMeter
y el agradecimiento personal a Carlos Cervantes y Salvador Acero , que consiguieron inculcarme los conocimientos que ahora transmito..
domingo, 30 de octubre de 2011
Evaluación de una herramienta de pruebas de rendimiento
1 ¿Por qué una herramienta de Pruebas de Rendimiento?
El objetivo de las pruebas de rendimiento (performance testing) es simular el comportamiento de una aplicación o sistema cuando sobre él actúan de manera concurrente un número elevado de usuarios.
El propio objetivo de las pruebas obliga a disponer de algún tipo de herramienta que permita "inyectar" la actividad de cientos o miles de usuarios y además obtenga los indicadores de rendimiento (tiempos de respuesta, transacciones/hora, consumo de recursos, etc..)
Existen multitud de herramientas que permiten realizar pruebas de carga. Para realizar una selección adecuada debemos fijar unos criterios de evaluación que nos permita seleccionar una herramienta que se adapte a nuestras necesidades y presupuesto.
2 Criterios de evaluación.
Veamos algunos criterios que tenemos que tener en cuenta a la hora de elegir una herramienta de pruebas de rendimiento. El siguiente mapa mental nos puede servir de guía.
2.1 Protocolos/Productos de las aplicaciones bajo pruebas
La herramienta debe soportar la tecnología y protocolo de la aplicación bajo
Suscribirse a:
Comentarios (Atom)