Unix (I).Conoce a tu amigo.

En esta serie de artículos, vamos a intentar explicar algunos de los comandos útiles, a la vez que exóticos que incluye Unix en algunas de sus versiones.

Aunque no es nuestro objetivo, comentamos que Unix ha tenido a lo largo de su ya longeva vida, distintos fabricantes y desarrolladores que han creado distintas versiones (o “flavours”, literalmente “sabores”) que en ocasiones producen quebraderos de cabeza a los que se inician en este sistema operativo. Entre otras, sin ánimo de ser exhaustivo

• Sun Solaris
• HP-UX
• AIX (IBM)
• BSD
• SCO Unix
• Red Hat Linux
• Slackware

Las distintas versiones muestran salidas diferentes para un mismo comando, no reconocen opciones de un comando o, directamente, nos encontramos que el comando no existe.

Nota: Cada vez que hagamos referencia a una ejecución de comando ,incluiremos el símbolo de prompt de Unix “$”.

Ejemplo: el comando “ps”, permite especificar valores específicos de los procesos a monitorizar, muestra salidas distintas según la versión de sistema operativo

$ps –eo PID,PPID,user,pcpu,rss,args -> Genera un listado de procesos ,con la siguiente salida

PID PPID user pcpu rss args PID : número identificador del proceso monitorizado PPID: Identificador del proceso padre User Usuario de sistema operativo al que pertenece el proceso pcpu Porcentaje de CPU consumida por el proceso (*) rss : Tamaño en Kilobytes de la RAM consumida por el proceso (*) args: Cadena de invocación del proceso, con argumentos, parámetros…etc

• SUN Solaris v 2.8, genera dicha salida de manera correcta

• Red Hat Linux , HP-UX generan dicha salida ,pero el consumo de CPU lo presenta sumando los porcentajes de uso de cada procesador físico de los que dispone la máquina

• AIX, indica que no reconoce los parámetros pasados al argumento “–o “

Aunque es posible solventar esta dificultad en cada sistema operativo para que la sentencia produzca los mismos efectos en todos ellos, es necesario utilizar al compañero imprescindible del usuario de consola de Unix (“man”) y encontrar los pasos necesarios para conseguir generar salidas compatibles System V.

Herramientas específicas

Características de plataforma

Pasamos ahora a describir algunos comandos útiles para averiguar las especificaciones de hardware de un sistema Unix

Sun Solaris

Para averiguar qué plataforma hardware ejecuta un sistema Sun OS, se debe usar el comando

$ uname –a > Esto genera una salida en la que,junto a la versión del sistema operativo, indica el modelo de máquina .

De la salida generada por el comando ,nos fijamos en el final de la misma

SunOS mortadelo 5.9 Generic_118558-34 sun4u sparc SUNW,Sun-Fire

Nos indica que el modelo de la máquina es una Sun-Fire. Para conocer exactamente las características de hardware (nº y velocidad de los procesadores, cantidad de memoria instalada... etc.) el procedimiento sería el siguiente

Una vez conocido el modelo, tendríamos que acceder a la ruta

/usr/platform/SunW,Sun-Fire

Ilustración 1. path utilidad prtdiag

Dentro del directorio, seleccionaríamos la carpeta “sbin”, donde nos encontraremos con la siguiente lista de ficheros ejecutables

eeprom fruadm prtdiag trapstat wrsmconf wrsmstat

En este caso, para averiguar las características de la plataforma, ejecutaríamos el comando “prtdiag”. Este comando genera secciones por cada componente general de la máquina

Por ejemplo CPU

Ilustración 2. prtdiag. Información procesadores

Esta salida indica la frecuencia de reloj de la máquina (150 MHz) -ojo, no de los procesadores -, el tamaño de la memoria instalada (24576 MBytes) y una línea descriptiva de cada procesador ,con su frecuencia ,identificador..etc.

Memoria

Ilustración 3.prtdiag informacion bancos memoria

Nos indica una línea por cada módulo instalado, tamaño , número de banco ..etc.

Tarjetas I/O

Ilustración 4. prtdiag. informacion tarjetas I/O

En cada línea nos describe las tarjetas específicas del equipo: interfaces de red, conexiones de fibra óptica para acceso a cabinas de discos externos, interfaces SCSI para acceso a dispositivos internos (discos, CD..)

Distribución de tarjetas y placas para dominio (si aplica)

Ilustración 5. prtdiag. Información placas y dominios

Este listado nos muestra las placas base de CPU instaladas (a lo largo de las se distribuyen todos los procesadores físicos) ,así como las placas disponibles para incrementar la capacidad de la máquina o para la creación de dominios.

Nota: una dominio en Solaris es una compartición de una máquina Sun, en la que una parte de la misma (CPUs, placas,tarjetas ) se dedica a una máquina y el resto a otra(s).

Linux

Una búsqueda rápida en Google nos muestra varias opciones para generar dicha información en las distintas distribuciones de este sistema operativo

• lshw ;Este comando genera un listado de todas las características hardware de la máquina
• dmesg |more ; buscamos los mensajes de arranque de sistema, en el que nos muestra entro otros, las características de hardware
• dmidecode | more; Nos muestra todas las características del hardware, fabricante, CPUs, tarjetas, puertos instalados…

HP-UX.

Existe una utilidad que sirve para gestionar todo el sistema en esta versión de UNIX ,llamada SAM (System Administration Manager) . Este comando, ejecutado en modo consola , abre un menú en el que ,entre temas de administración de usuarios, sistemas de ficheros ...etc, permite averiguar la configuración del hardware).

Indicar que este es un comando en modo privilegiado, por lo que sólo se puede ejecutar o bien como root o bien como un usuario autorizado para ello

sam –r usuario_restringido

La próxima entrega de este serial: Configuración de sistema ¿dónde está el condenado fichero que busco?

Demo de HP LoadRunner 11.0 TruClient

Mejores Practicas Rendimiento (Top10)

1. Utilizar diferentes identificadores de sesión.
2. Utilizar datos dinámicos en las operaciones que se vayan a realizar.
3. Para las aplicaciones que acarrean datos, se deberán parametrizar estos datos.
4. 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.
5. 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.
6. No sobrecargar los equipos desde los cuales se está generando la carga, esto puede distorsionar los resultados y hacerlos poco fiables.
7. Siempre en cada ejecución tener las mismas condiciones de ejecución (Entorno, Recursos, Generadores de Carga.)
8. Introducir y Finalizar la carga gradualmente, para evitar comportamientos abruptos del sistema.
9. Identificar los criterios de aceptación de rendimiento y evaluarlos según el resultado de la prueba.
10. Validación exhaustiva de las peticiones que se lanzan, para no provocar resultados incoherentes.

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.

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

http://josepablosarco.wordpress.com/

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=JMeterFunciones

Y como elemento de utilidad, el evaluador de expresiones regulares on-line de JMeter

http://jakarta.apache.org/oro/demo.html

y el agradecimiento personal a Carlos Cervantes y Salvador Acero , que consiguieron inculcarme los conocimientos que ahora transmito..