R3b3l10Nn

El tamaño de los flujos de prueba no siempre es breve, lo que dificulta su correcta transformación en scripts de JMeter. No solo por el hecho de ser extensos, sino también por las necesidades que acarrea al momento de parametrizar. Como he mencionado en algunas entradas anteriores , algunas veces es necesario parametrizar casi por completo el script de JMeter. Es el caso si la aplicación tiene componentes de Seam. El ocio, como bien dice Jason Cannon, es la madre de la automatización y el uso de rutinas para las tareas repetitivas. A continuación vamos a hacer vía bash con la cual podemos sustituir los parámetros cid y viewstate en los .jmx de JMeter, hecho que nos facilitará la vida de manera sustanciosa, inclusive, evitando posibles errores de dedo que no hacen otra cosa que fastidiarnos las pocas horas que debemos dedicar a labores de preparación de los scripts . GNU/Linux está dotado de herramientas muy poderosas para el manejo de archivos de texto, como Perl, AWK, ...

A veces la vida de las personas que hacemos pruebas de rendimiento es complicada, en especial, cuando nos encontramos frente a un framework de desarrollo poco amigable en términos de comprensibilidad en la conformación de las peticiones http . La aplicación hacía muchas redirecciones, peticiones ajax , llenado de campos en automático, uso de tablas, etc. Seam construye de una manera particular las vistas, para ello se apoya en dos variables: cid y viewstates . Los valores de éstos son únicos y por lo tanto, el software de estrés debe ser capaz de reescribir esta variable...pero sí no lo hace, hay que realizar unos cuantos pasos adicionales. Yo uso Jmeter, así que sólo será válido mi procedimiento para este software . Lo primero que debemos hacer es agregar a cada página .seam dos post-processor : Regular Expression Extractor . Uno para cid y otro para el viewstate . A continuación se muestra el cómo deben configurarse los extractores. El nombre por el cual lo ubi...

Introducción Últimamente me he interesado por la información que podemos obtener mediante los logs para utilizarla de forma proactiva. Por lo normal utilizamos los registros para detección de anomalías o desperfectos que afectan la operación de una aplicación, pero rara vez utilizamos toda la información que compone un log para proyectar un comportamiento u obtener el diagnóstico de cómo opera con "normalidad" nuestro sistema.  En esta entrada de blog me gustaría realizar un análisis que responda a la pregunta ¿vale la pena invertir horas en la optimización de código en una aplicación web? . Para ello, nos enfocaremos en la correlación de los tiempos de respuesta (aka TR) y el número de peticiones que el sistema resuelve en un periodo de tiempo. Podríamos auxiliarnos de pruebas de estrés, sin embargo, algunas veces no disponemos de los ambientes necesarios, y solo nos queda hechar mano de los registros productivo, aún así, es decisión de cada quién cómo obtener l...