R3b3l10Nn

SAR es la herramienta por excelencia para el monitoreo de los sistemas operativos GNU/Linux. Cuenta con históricos, además de una gran cantidad de métricas relacionadas al desempeño de nuestro servidor, como cpu, memoria, I/O y red. Cada uno de estos hitos puede ser diseccionado con mayor granularidad, es decir, observar la parte que compone cada recurso. Algunas veces es necesario realizar reportes de desempeño a otras áreas o incluso para efectos de conocimiento de patrones de utilización de cada servidor. Por desgracia, las formas de llevar a un modelo de visualización más amable es tarea un poco más complicada y no está incorporada por defecto con SAR. Existen herramientas ex profeso, sin embargo, tienen que ser utilizadas con cierta complejidad y algunas veces no producen el resultado deseado, como por ejemplo, gráficas de muy pobre visualización. En lo personal me gusta graficar las métricas; son una manera muy simple de entender lo que sucede y enfocarnos en los momento...

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...

Un monitoreo pobre durante las pruebas de QA se traduce en problemas y dolores de cabeza en producción, en especial, para los administradores. En las aplicaciones basadas en Java, existen componentes intrínsecos a los servidores de aplicaciones/JVM, como el GC. También existen los componentes de las aplicaciones, como los hilos http o las conexiones abiertas hacia base de datos o ldaps. Es importante tener la visión completa desde que llega una petición hasta que ésta es retornada. Tengo que decir que debemos ser cuidadosos con los costos de la demasía en el monitoreo, en especial, por el overhead que ésto conlleva. En papel o en una herramienta de software, es posible realizar un mapa con las dependencias a otros servicios, la interacción que tiene; el cual posteriormente podemos anexar en el test plan . Ésto nos ayudará a plasmar y detectar los sitios donde colocaremos nuestros scripts recolectores. El leitmotiv de este post es describir la importancia de mirar las entr...

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...