En el encuentro GeneXus se presentó en conjunto a gente de GeneXus Consulting y de Ancap, la experiencia de un proyecto en el cual se realizaron pruebas de performance, y luego pruebas automatizadas, todo con el apoyo deGXtest.
Presentaron Andrei Guchín (de Abstracta), Lorena Campistrous (de Ancap) y Mauro Álvez (de GXC).
Fotos, material y video de la charla, en este link.
El Sistema Bajo Pruebas: Sisper
Se trataba de un sistema que cuenta con más de 2500 usuarios (todos los funcionarios de ANCAP y los tercerizados) que entre otras cosas pueden consultar sus horas trabajadas.
Etapa de Diseño de Pruebas
Presentaron Andrei Guchín (de Abstracta), Lorena Campistrous (de Ancap) y Mauro Álvez (de GXC).
Fotos, material y video de la charla, en este link.
El Sistema Bajo Pruebas: Sisper
Se trataba de un sistema que cuenta con más de 2500 usuarios (todos los funcionarios de ANCAP y los tercerizados) que entre otras cosas pueden consultar sus horas trabajadas.
El proyecto implicó una evolución tecnológica del sistema. Hubo un cambio en la arquitectura, pasando de una aplicación Cliente-Servidor a un portal de autogestión Web. Para lograr esto, y aprovechar el potencial que brinda GeneXus en sus últimas versiones, se migraron las KB’s de versiones anteriores a la Evolution 1.
También se hizo una reingeniería de las funcionalidades más complejas que se encargan de procesar las horas trabajadas para generar los datos para la interfaz de sueldos y para visualizarlas en detalle.
Pruebas de Performance
Cuando hablamos de pruebas de performance, nos estamos refiriendo al tipo de pruebas que tienen por objetivo determinar el rendimiento o la capacidad de respuesta de un sistema sometido a una determinada carga. En otras palabras, lo que se busca es ver si el sistema soporta la carga actual o la proyectada. Para lograr esto, se genera carga en el sistema con herramientas especializadas a la vez que se monitorizan los recursos. Un proyecto de performance, se divide básicamente en tres grandes etapas: diseño, automatización y ejecución y análisis de resultados.
También se hizo una reingeniería de las funcionalidades más complejas que se encargan de procesar las horas trabajadas para generar los datos para la interfaz de sueldos y para visualizarlas en detalle.
Pruebas de Performance
Cuando hablamos de pruebas de performance, nos estamos refiriendo al tipo de pruebas que tienen por objetivo determinar el rendimiento o la capacidad de respuesta de un sistema sometido a una determinada carga. En otras palabras, lo que se busca es ver si el sistema soporta la carga actual o la proyectada. Para lograr esto, se genera carga en el sistema con herramientas especializadas a la vez que se monitorizan los recursos. Un proyecto de performance, se divide básicamente en tres grandes etapas: diseño, automatización y ejecución y análisis de resultados.
Proyecto de Pruebas de Performance para Sisper
Los objetivos de las pruebas realizadas en el Sisper fueron mitigar riesgos asociados a la salida en producción así como optimizar el sistema como para obtener el mejor desempeño posible. Veamos a continuación cómo se avanzó en las distintas etapas del proyecto de pruebas de performance.
Etapa de Diseño de Pruebas
Uno de los objetivos principales de esta etapa es definir la carga del sistema. Para eso se trabajó con datos estadísticos obtenidos del sistema en su versión previa. Se pueden ver en la siguiente gráfica el acceso a lo largo de un día de uso del sistema, detectado así cuál es la hora de mayor carga del sistema.
En base a estas estadísticas y a los aportes realizados por el equipo de Ancap y GeneXus Consulting, se seleccionaron aquellos casos de prueba más utilizados, más pesados o más críticos para el sistema, tomando en cuenta el detalle de datos de la hora pico de uso del sistema. Con los casos de prueba seleccionados (en total 13), se diseñó un escenario de prueba donde se especifica la cantidad de usuarios que van a ejecutar cada una de las funcionalidades seleccionadas, cuántas veces la van a ejecutar cada uno, etc. Esto se puede ver en la siguiente tabla.
.png)
Etapa de Automatización
Luego de establecido el escenario, continuamos con la automatización de estos casos de prueba.
Las herramientas utilizadas para esto, tales como OpenSTA, trabajan a nivel de protocolo lo que produce que la tarea de automatizar requiera mucho esfuerzo, llegando incluso a ocupar el 50% del tiempo del proyecto.
Para reducir esto, grabamos los casos de prueba con GXtest ya que permite hacerlo de una manera más fácil y práctica y luego utilizamos una de sus funcionalidades para generar automáticamente los scripts para OpenSTA. Para entender más sobre esta funcionalidad les recomendamos leer este post. Se trata de una nueva funcionalidad de GXtest que permite generar scripts para OpenSTA a partir de scripts funcionales.
Lo bueno de este enfoque es que permite:
Para la monitorización de recursos se utilizaron varias herramientas, como por ejemplo:
A raíz de estas pruebas y el análisis conjunto entre analistas funcionales, desarrollo, testing e infraestructura, se pudieron llevar a cabo cambios y ajustes que en conjunto tienen un impacto importante sobre el sistema:
En líneas generales se pudieron alcanzar los objetivos planteados en el proyecto contribuyendo a mitigar riesgos importantes en la salida en producción del nuevo SisPer. Se lograron resolver irregularidades y realizar ajustes que ayudan a obtener un mejor desempeño. Aparte de los objetivos alcanzados se lograron otros beneficios indirectos de las pruebas de performance como son el entrenamiento de las personas encargadas de infraestructura para la detección y análisis de problemas en producción.
Como extra, este proyecto dio el puntapié inicial a la automatización de pruebas funcionales, ya que al contar con algunos casos de pruebas automatizados para las pruebas de performance, se aprovecharon los test cases de GXtest con otro propósito.
Queremos resaltar también la importancia dada a las pruebas por parte de la gerencia, visualizando el valor de las pruebas de performance para la disminución de riesgos. Por otra parte felicitar y agradecer a todo el equipo por la buena experiencia de trabajar con ellos.
En base a estas estadísticas y a los aportes realizados por el equipo de Ancap y GeneXus Consulting, se seleccionaron aquellos casos de prueba más utilizados, más pesados o más críticos para el sistema, tomando en cuenta el detalle de datos de la hora pico de uso del sistema. Con los casos de prueba seleccionados (en total 13), se diseñó un escenario de prueba donde se especifica la cantidad de usuarios que van a ejecutar cada una de las funcionalidades seleccionadas, cuántas veces la van a ejecutar cada uno, etc. Esto se puede ver en la siguiente tabla.
.png)
Etapa de Automatización
Luego de establecido el escenario, continuamos con la automatización de estos casos de prueba.
Las herramientas utilizadas para esto, tales como OpenSTA, trabajan a nivel de protocolo lo que produce que la tarea de automatizar requiera mucho esfuerzo, llegando incluso a ocupar el 50% del tiempo del proyecto.
Para reducir esto, grabamos los casos de prueba con GXtest ya que permite hacerlo de una manera más fácil y práctica y luego utilizamos una de sus funcionalidades para generar automáticamente los scripts para OpenSTA. Para entender más sobre esta funcionalidad les recomendamos leer este post. Se trata de una nueva funcionalidad de GXtest que permite generar scripts para OpenSTA a partir de scripts funcionales.
Lo bueno de este enfoque es que permite:
- Ahorrar muchísimo tiempo en la creación de los scripts.
- Las pruebas quedan automatizadas en GXtest, lo cual también nos sirve como pruebas funcionales de regresión automáticas.
Etapa de Ejecución y Análisis de Resultados
Luego de automatizados los casos, se comenzó con la ejecución de las pruebas. Se considera una buena práctica comenzar con menor carga que la determinada en el escenario (por ejemplo, un 25%) e ir aumentándola gradualmente a medida que las ejecuciones van dando resultados positivos. Esto permite encontrar primero los problemas más grandes, que generalmente son los más importantes a corregir y los que afectan más la performance.Para la monitorización de recursos se utilizaron varias herramientas, como por ejemplo:
- iSeries Navigator de IBM, para la monitorización del sistema operativo y desempeño de la base de datos.
- JConsole, para la monitorización de indicadores de la Java Virtual Machine y otros indicadores expuestos específicamente por GeneXus.
- Performance monitor de Microsoft, para monitorizar las generadoras de carga.
- Tivoli Performance Viewer de IBM, para analizar los tiempos de los servlets y el comportamiento del heap de la JVM.
- IBM Heap Analyzer, para el análisis de la memoria de la JVM.
- JProfiler de e-techologies, para el estudio detallado del consumo de tiempo de distintas funcionalidades.
A raíz de estas pruebas y el análisis conjunto entre analistas funcionales, desarrollo, testing e infraestructura, se pudieron llevar a cabo cambios y ajustes que en conjunto tienen un impacto importante sobre el sistema:
- Se realizaron cambios funcionales que redujeron notoriamente el uso de los recursos del servidor, en particular consumo de CPU y memoria del lado del servidor. También se mejoró el ancho de banda utilizado, y se solucionaron problemas de estabilidad.
- También se realizaron ajustes que mejoraron los tiempos de respuesta, el uso de recursos de acceso a los datos y se redujeron las posibilidades de bloqueos en tablas de GXflow.
En líneas generales se pudieron alcanzar los objetivos planteados en el proyecto contribuyendo a mitigar riesgos importantes en la salida en producción del nuevo SisPer. Se lograron resolver irregularidades y realizar ajustes que ayudan a obtener un mejor desempeño. Aparte de los objetivos alcanzados se lograron otros beneficios indirectos de las pruebas de performance como son el entrenamiento de las personas encargadas de infraestructura para la detección y análisis de problemas en producción.
Como extra, este proyecto dio el puntapié inicial a la automatización de pruebas funcionales, ya que al contar con algunos casos de pruebas automatizados para las pruebas de performance, se aprovecharon los test cases de GXtest con otro propósito.
Queremos resaltar también la importancia dada a las pruebas por parte de la gerencia, visualizando el valor de las pruebas de performance para la disminución de riesgos. Por otra parte felicitar y agradecer a todo el equipo por la buena experiencia de trabajar con ellos.
--
Saludos,2014-05-07 17:36 GMT-03:00 Fabián Baptista <fabianbaptista@gmail.com>:
de nada, adjunto, saludos,2014-05-07 17:06 GMT-03:00 Usuario Genexus <usuariogx.mexico@gmail.com>:
Gracias Fabian por contestar, me interesa si me puedes enviar la documentación que me dices en el punto 2-b, vamos a trabajar en Java e Informix y en Linux en Ev 2 y mas adelante evaluar si nos cambiamos a la versión 3, actualmente no tenemos la plataforma completa, pero si un aproximado. Queremos hacer pruebas de rendimiento al inicio del proyecto para empezar a detectar los problemas que podamos encontrar y comenzar a trabajar en ellos. Voy a revisar los links que me mandaste.Gracias Wilman y estoy totalmente de acuerdo contigo, estamos pensando cargar en un WP 100,000 registros, estos es por la misma necesidad del sistema a desarrollar y por eso mismo necesito hacer pruebas de performance para conocer cual es la mejor forma de traerme todos esos datos ya sea para 1 o 100 usuarios.SaludosAlejandroEl 7 de mayo de 2014, 13:40, Fabián Baptista<fabianbaptista@gmail.com> escribió:
Estimado, entiendo que estas realizando varias consultas, intento contestar por partes que me parecen importantes:1) Para evaluar el rendimiento deberías hacer pruebas de performance, en este artículo del blog se comenta una experiencia en particular: http://blog.abstracta.com.uy/2012/10/experiencia-de-pruebas-de-performance.htmlVideo usando GXtest y OpenSTA: http://vimeo.com/356500902) Para evaluar el RENDIMIENTO te recomiendo 2 cosasa) Crear indicadores específicos para los servidores en cuestión que permitan medir recursos básicos (CPU, MEM, Cola de disco, %time GCollector, etc.). Si tenes Windows podes hacer casi todo con perfmon, de lo contrario podes usar nMON u lo que cada S.O tenga.b) Evaluar indicadores de performance específicos de GeneXus como tiempos de respuestas de los procedimientos, usuarios, cache, TOP SQl's, etc.:Si es .NET usando WMI, si es Java, usando JMX. Puedo enviarte documentación si quieres habilitar dichos indicadores y monitorizarlos.3) Para evaluar el consumo de N usuarios, haces la prueba de performance y medis los tiempos de respuesta e indicadores de recursos a la misma hora (sincronizar relojes)4) Información sobre esto puedes encontrar en blog.abstracta.com.uy y en la wiki de genexus.5) Genexus no es lento, hay que saber muy bien qué se está haciendo para hacerlo bien. Luego, como todo, hay que testear, medir y arreglar lo que tenga problemas.saludos,2014-05-07 14:22 GMT-03:00 Usuario Genexus <usuariogx.mexico@gmail.com>:
Buen día, tengo una serie de dudas que si alguien del foro pudiera contestarme o indicarme donde puedo encontrar información al respecto. Todo es relacionado al rendimiento de una aplicación web. Necesito saber como evaluó el rendimiento de una aplicación que instalo en el servidor, esto es, tengo una aplicación instalada en un servidor, el cual en determinado momento necesito obtener 5,000 registro o hasta 30,000. Hago una consulta por procedimiento y lo obtengo en formato JSON, hasta ahí todo bien, para un usuario puedo "evaluar",Que pasa para 10 o 20 o 100 usuario?, esta aplicación no es la única en el servidor,Como evaluar el porcentaje de procesador se esta utilizando para n usuarios?.Vamos a utilizar Gx, pero trato de dar mas argumentos a mis jefes de que Gx no es lento con grandes cantidades de datos (en algún momento podemos llegar a pedir hasta 100,000 registros en una consulta).Donde puedo encontrar información acerca de esto, pero específicamente para Gx?.Espero alguien me pueda orientar.Saludos
Has recibido este mensaje porque estás suscrito al grupo "GeneXus" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a genexus+unsubscribe@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
0 Response to "Re: [testandmonitoring] Rendimiento"
Publicar un comentario