Herramientas … en testing de Performance

Al momento de evaluar la performance de un sistema se debe ejercitar el mismo con una determinada carga con el fin de evaluar su desempeño. Si bien se podría invitar a todos los potenciales usuarios del sistema y pedirles que “hagan sus actividades” en el sistema mientras los ingenieros evalúan el comportamiento del mismo, esto en la mayoría de los casos es imposible o tiene muchas desventajas.

 

 

Como mencionamos semanas atrás en una de las charlas, que tuvimos el gusto de compartir en el Testing Day, cuanto más distribuidos están los potenciales usuarios del sistema – más complejo será sincronizar la prueba (momento en que comenzamos la prueba). Y cuantos más sean los usuarios – más costosa será la “prueba” ya que se  tendrá que pagar horas extras a cada una de las personas que vayan a participar de la simulación (seguramente no es viable parar la empresa, es decir las actividades cotidianas para realizar las simulaciones) y se necesitará una estación de trabajo para que esta persona pueda operar con el sistema… el caso en que esta estación de trabajo no sea un simple PC (sino por ejemplo un cajero automático – cómo se vió en un post anterior) también influirá en la cantidad de tiempo que tengo para utilizarlo ya que son horas que tendré que arrendar ese recurso (o no lo tengo disponible para otras actividades).

 

 

Por este motivo es necesario utilizar una herramienta que permita automatizar las distintas acciones que realizan los usuarios en el sistema para luego modelar la realidad de uso del mismo y poder estudiar su comportamiento. Para dicha automatización existen distintas herramientas Open Source y comerciales, que son de utilidad a la hora de hacer una prueba de performance.

 

 

Esta solución a diferencia de las simulaciones con usuarios reales (en vez de virtuales) tiene la ventaja de que es escalable. Es decir, una vez que una máquina capaz de generar carga alcanza su “tope” de cantidad de usuarios y sea necesario generar más carga, se pueden agregar más máquinas y se tiene un potencial para ejecutar cientos de usuarios MÁS. Esto no tiene asociado mayores costos que el tiempo de los responsables asignados para la configuración de la herramienta y la posterior ejecución de cada prueba… En próximos posts intentaremos responder las siguientes preguntas:

¿Por qué es necesaria una prueba de performance?

¿Por qué es necesario utilizar una herramienta?

¿Cómo elegir una herramienta adecuada?

 

Hasta la próxima! saludos.

Gustavo Guimerans

Especialización en testeo de portales

En los últimos años se ha incrementado el uso de portales en Internet, sitios web que ofrecen al usuario acceso a recursos y servicios relacionados. A modo de ejemplo se encuentran links, buscadores, foros de discusión, documentos, aplicaciones, e-commerce, entre otros.

La disciplina de pruebas de performance intenta modelar el uso que los usuarios de una aplicación le dan a la misma a fin de detectar posibles cuellos de botella, aislarlos e intentar, con un equipo de expertos en la infraestructura y la aplicación, realizar cambios hasta encontrar la mejor configuración.

En el CES realizamos a diario pruebas de performance sobre distintos tipos de aplicaciones, con más o menos capas y distintas tecnologías. Contamos con una metodología la cual ha sido reconocida a nivel internacional. Si bien cada sistema tiene sus particularidades, las ideas generales para realizar un buen modelado de la realidad son similares.

En este artículo voy a centrarme en aspectos comunes para realizar pruebas de performance en portales. La principal particularidad se encuentra en la etapa de relevamiento, aquí a diferencia de otras aplicaciones, podrán estar integradas varias aplicaciones con lo cual se hace necesario identificarlas y, en base a ellas, seleccionar las herramientas a incluir para realizar la automatización. Luego, por cada una de estas aplicaciones, habrá que realizar las actividades que proponemos en nuestra metodología (Relevamiento, Automatización, Armado de la Infraestructura definitiva y Ejecución). Finalmente se deberá ejecutar una prueba en conjunto con todas las aplicaciones que brinda el portal, a fin de modelar su verdadero uso.

Una simplicidad que se da a diferencia de sistemas transaccionales es lo relacionado a la generación de datos. Ya que salvo excepciones, a priori no se consumen los datos utilizados para las pruebas. Lo cual al realizar varias pruebas complica el proceso, ya que la ejecución y posterior comparación queda ligada a la posibilidad de volver a un estado conocido el estado de la aplicación (incluyendo todos los componentes de la infraestructura, ej.: bases de datos).

Lo que más difiere últimamente entre portales y otro tipo de aplicaciones es lo relativo a facilidades que se le brinda al usuario.Ejemplos de esto son el “single sign on” y lastecnologías que apuntan a mejorar la percepción del usuario, como ser Ajax, Silverlight, flash, entre otras…que se dan más desde el lado del cliente. Todo esto habrá que considerarlo y ver la forma de emularlo a fin de lograr una carga similar a la que el portal estará recibiendo una vez en producción.

Lo otro que cambia, es el modelado del tráfico y del comportamiento de los usuarios. No es lo mismo a un sistema en donde el usuario tiene que usarlo y finalizar una tarea. Un portal es diferente. Por ejemplo, se tiene abandono de los usuarios (usuarios que abandonan el portal a la mitad de algo y no terminan transacciones), usuarios que buscan algo y no lo encuentran…

La literatura, en general, dice que hay que basarse en logs de navegación de portales similares o anteriores para poder determinar un escenario de uso lo más real posible.Este tipo de informaciónno siempre está disponible con lo cual muchas veces se estima en base entrevistas la simulación del uso del portal a generar. Asimismo, se intenta tipificar usuarios además de transacciones (lo que generalmente se tipifica), ya que para una misma transacción hay gente que puede llegar a utilizarla de manera diferente. A modo de ejemplo si la transacción fuese “consultar horarios de trámites” algunos usuarios tal vez solo consulten esos horarios y los impriman y otros de allí pasen a solicitar un número para realizar un trámite.

En conclusión, dado que los usuarios tienen un comportamiento diferente y son potencialmente diferentes para cada ejecución de la transacción (no es como en un sistema transaccional en donde se loguea una vez y nada más) es que la forma de modelar la realidad se basa en el comportamiento que los usuarios le dan al sistema más que en las funcionalidades.

Gustavo Guimerans

Metodología de pruebas de Performance del CES

Desde hace unos años venimos utilizando una metodología propia para llevar adelante proyectos de pruebas de performance que nos ha dado muy buenos resultados.

Hemos tenido el agrado de escribir varias publicaciones al respecto y presentarlas en diferentes eventos (Expo QA 2008SEPGLA 2008)  recibiendo un muy buen feedback.

La metodología es lo suficientemente amplia para abarcar varios tipos de proyectos pero a su vez da una guía muy útil a la hora de abordar estos temas.

En este post me gustaría comentar brevemente las diferentes estapas de la metodología y cuál es el objetivo de cada una.

Etapas de pruebas de performance

Etapa inicial

Se busca entender el contexto en el cual surge el proyecto y los objetivos que se persiguen. Se busca también, dimensionar el proyecto de testing de performance, acotando su alcance. Se requieren en general pruebas de concepto para analizar que herramientas se adecuan mejor al contexto y al sistema que se tiene que probar. Al finalizar esta etapa tenemos que tener una idea clara del esfuerzo necesario para llevar adelante el proyecto,  perfiles de gente se a involucrar, los recursos  materiales se van a necesitar, etc.

Etapa de Relevamiento

Es una de las etapas fundamentales del proyecto. Se busca definir un modelo que simule de la manera más adecuada posible la realidad a la cual se va a enfrentar el sistema. En esta etapa debemos integrar personas con distintos perfiles (usuarios, analistas funcionales, desarrolladores, administradores, etc.) para definir qué transacciones se incluirán, cuántos usuarios virtuales se ejecutarán, cada cuánto tiempo, cómo se simularan otros sistemas, etc. Se deben tener en cuenta todos estos factores para reproducir las condiciones bajo las cuales se quiere estudiar el sistema.

También se deben detallar otros aspectos importantes como ser: la infraestructura que se utilizará para las pruebas, como se monitorizará la misma, los datos a utilizar en las pruebas, etc.

Etapa de Automatización

En general en las pruebas de performance debemos programar para simular el modelo definido en la etapa anterior. Este modelo en general incluye la necesidad de ejecutar funcionalidades con alta concurrencia. Para poder lograr esto, en general, las herramientas trabajan a nivel de protocolo. Para protocolos abiertos y ampliamente difundidos como HTTP existe una variedad importante de herramientas gratuitas y pagas, pero para protocolos propietarios es más complicado encontrar herramientas gratuitas (tal como comentamos en un post anterior).

Al finalizar esta etapa se contará con todos los artefactos de prueba necesarios para recrear el modelo definido.

Etapa de Armado de la Infraestructura definitiva

Luego que se ha dedicado mucho esfuerzo definiendo y programando la automatización, es hora de dejar el ambiente de pruebas listo para comenzar las ejecuciones. Esta etapa en general ocurre luego de la etapa de automatización debido a que por lo general los servidores a utilizar en las pruebas tienen un costo alto y se intenta minimizar el uso de los mismos. Las etapas anteriores se pueden realizar con un ambiente similar al que se va a utilizar en las pruebas.

Al finalizar esta etapa se tiene toda la infraestructura lista para la ejecución, eso incluye la monitorización (tanto de los servidores como de las generadoras de carga), procesos de backup/restore en caso de que sean necesarios, etc.

Etapa de Ejecución

En esta etapa se comienza a obtener los resultados. Generalmente las ejecuciones las comenzamos con las llamadas líneas bases (baselines) las cuales consisten en ejecutar cada transacción sin concurrencia ninguna (con la totalidad de los recursos disponibles) para obtener el mejor tiempo posible de cada una. Estos tiempos nos servirán luego como puntos de comparación. Al comenzar las pruebas se recomienda asignar un porcentaje de carga bajo (por ejemplo un 20% de la carga que se desea soportar), si todo funciona según lo esperado subir al 40%, y así hasta llegar al 100% o 200% si se desea. La razón fundamental para tomar esta estrategia es encontrar con un nivel de complejidad menor los problemas más gruesos, atacarlos y luego pasar al siguiente escalón. Si se ejecutaría de primera el escenario objetivo puede pasar que ocurran varios problemas al mismo tiempo, agregando complejidad  al análisis de los mismos.

Luego de varias iteraciones de ejecución, reportes y correcciones (lógica, configuración, re-diseño, etc.) se llega a una versión del sistema que cumple con los desafíos planteados, o no se llega y se aprende sobre los puntos en los cuáles se debe mejorar.

Es muy importante tener en cuenta que durante esta etapa el objetivo es mejorar el sistema y por este motivo se deben involucrar tanto los testers como los desarrolladores, los expertos en el DBMS, en el sistema operativo, en el balanceador de carga, en el servidor web, en el storage, etc, etc.

Etapa de Finalización

Luego que se terminan las ejecuciones es aconsejable hacer un informe final en el cual se cuente  el desarrollo del proyecto, qué mejoras se hicieron qué sugerencias quedan por implementar para mejorar la performance, etc. También es aconsejable hacer una evaluación postmortem en la cual se vean los puntos a mejorar y ajustar para el próximo proyecto.

Esperamos les sea útil esta información y pueda contribuir en la mejora de la performance de sus sistemas.

Matías Reina

Pruebas de Performance en protocolos menos usuales (caso sistema financiero ISO8583)

En el laboratorio de Ensayos de Plataformas del CES realizamos usualmente Performance Testing a aplicaciones web que ejecutan sobre el conocido protocolo abierto HTTP, para lo que utilizamos algunas herramientas, ya sean pagas o gratuitas, como ser Microsoft Visual Studio Team System, JMeter, OpenSTA, entre otras. Las pruebas de performance (a diferencia de las pruebas funcionales) necesitan manejarse a nivel de protocolo para poder ser más eficientes y simular cientos de usuarios en una sola máquina.

Pero, ¿qué sucede si queremos realizar pruebas de performance de aplicaciones que manejan protocolos distintos y quizás menos usuales que HTTP? En muchos casos, las herramientas que presentamos anteriormente pueden ser capaces de soportar directamente el protocolo, o al menos brindarnos la oportunidad de simularlo luego de algunas configuraciones adicionales. Si este no es el caso, no queda otra alternativa que entender en detalle las especificaciones del protocolo e implementar por cuenta propia módulos o herramientas que permitan establecer una comunicación, y en particular para las pruebas de performance, que permitan generar cierta carga parametrizable mediante este protocolo.

En varios proyectos del CES en el sector financiero nos hemos encontrado con un protocolo ampliamente difundido en estos entornos, este es el ISO8583. Este protocolo es utilizado para el intercambio de información financiera, principalmente por ATMs (Automatic Transaction Machine) y POS (Point of  Sale). En definitiva, cuando realizamos un retiro de un cajero automático o una compra en un local de venta utilizando nuestra tarjeta de crédito/débito, estamos estableciendo una comunicación via ISO8583 con una institución financiera, cuyo sistema de administración de tarjetas se encargará de procesar la petición recibida y enviar una respuesta indicando el resultado de la transacción. Este componente que procesa la información, típicamente se llama Switch Financiero.

Como mencionabamos previamente, debido a que ninguna de las herramientas disponibles en nuestro laboratorio fue capaz de soportar naturalmente el ISO8583, optamos por desarrollar nuestra propia herramienta generadora de carga, la cual fue desarrollada en Java. Cabe comentar de todos modos que, en el mundo open source, se pueden encontrar diversas herramientas que implementan este protocolo, permitiendo enviar mensajes mediante el mismo hacia un switch financiero (problema también abordado en el CES y que comentaremos en futuros post sobre experiencias de Testing Funcional), pero ninguna de ellas cumple el requerimiento fundamental de toda prueba de performance: permitir la generación automática de carga masiva. Luego de varios meses en los cuales debimos entender la especificación del estándar y desarrollar la aplicación acorde al mismo, junto con posteriores modificaciones de mejora logramos obtener una herramienta estable capaz de soportar hasta 200 transacciones por segundo en una única máquina de escritorio, cifra más que aceptable en un principio.

El contar con esta herramienta, y poder utilizarla en conjunto con otras para poder simular todos los puntos de entrada de un core financiero, nos ha permitido llevar adelante exitosamente múltiples proyectos en los cuales ha estado involucrado nuestro laboratorio, logrando generar la carga requerida para poder cumplir los objetivos primordiales de una prueba de performance. En posts subsecuentes estaremos describiendo en detalle cuales son estos objetivos.

Matias Nassi