Cómo realizar un análisis de rendimiento para sistemas informáticos distribuidos

En este segundo artículo de nuestra serie de dos partes sobre análisis de rendimiento en sistemas informáticos distribuidos, nos centraremos en los requisitos del plan de prueba y en el proceso de prueba en sí. Además, veremos cómo el benchmarking de rendimiento puede cuantificar el impacto de las modificaciones del sistema.

El plan de prueba

El plan de prueba es una parte fundamental del proceso de análisis de rendimiento, aunque a menudo se pasa por alto. Es importante detallar en el plan los objetivos y las expectativas de la prueba, tanto para el grupo de desarrollo como para otros directivos de la organización. Esto evita malentendidos y que los desarrolladores reclamen datos adicionales una vez finalizada la prueba. Además, el plan de prueba sirve como documento de comparación para futuros cambios en la aplicación.

El plan de prueba debe incluir los siguientes puntos:

• Dimensiones de la aplicación que se probarán y las razones para hacerlo.
• Configuración de la arquitectura de prueba.
• Procedimiento de prueba.
• Métricas que se recopilarán.
• Resultados esperados.

Asigna una sección del plan a cada uno de estos puntos. También es recomendable incluir una sección para los requisitos previos de la prueba, como la configuración del entorno o de la aplicación. Anota cualquier riesgo relacionado con el proceso de prueba o los resultados finales. Además, al describir los resultados esperados, detalla los pasos que se deben seguir si los resultados difieren significativamente de las expectativas iniciales.

El proceso de prueba

El objetivo principal de la prueba es obtener una visión completa y precisa del rendimiento del sistema para el equipo de ingeniería. Con base en los datos de prueba recopilados, se pueden tomar decisiones importantes, como las siguientes:

• Configuración de la aplicación.
• Decisiones de diseño de la arquitectura del sistema.
• Prácticas de codificación.
• Planificación de escalabilidad y capacidad.

Las mediciones de rendimiento de un sistema informático distribuido no siempre son consistentes. Muchas variables, más allá del nivel de aplicación, pueden afectar el rendimiento, incluso por períodos muy cortos. Por eso, asegúrate de que la prueba se realice durante un tiempo suficiente para suavizar estos picos y obtener una visión general del rendimiento. Por lo general, una medición de rendimiento a un nivel de carga constante debe durar varios minutos, mientras que una medición a un nivel de carga variable debe durar varias horas.

Micropagos: La solución para comprar artículos baratos en línea

El proceso de prueba se resume en unos pocos pasos sencillos:

1. Inicializar el entorno de prueba.
2. Ejecutar la prueba.
3. Recopilar los resultados.
4. Repetir el proceso.

Incluso con cinco o seis conjuntos de resultados, es posible calcular un valor promedio y un margen de error. Lo ideal sería tener el triple de datos para trabajar, pero a menudo resulta difícil convencer a los superiores de que se requiere tanto trabajo para lograr precisión.

Automatización con scripts de shell

Como sugerimos en el artículo anterior, es recomendable automatizar el proceso tanto como sea posible para reducir errores y ahorrar tiempo. Los scripts de shell remotos son una buena solución para automatizar parte del proceso en un entorno de servidores múltiples. Con herramientas como Cygwin, que permite una interfaz UNIX en Windows, incluso puedes extender estos scripts a entornos Windows sin demasiados problemas. Aquí tienes algunos scripts útiles:

• Automatización de compilación: Si necesitas comparar el rendimiento entre dos compilaciones de la aplicación, contar con un script que despliegue y configure la aplicación completa en las máquinas correspondientes en el entorno de prueba para una versión específica reduce el tiempo de configuración.
• Supervisión remota: La mejor fuente de métricas del sistema se encuentra en el propio sistema. Si no tienes acceso a una solución de supervisión remota de primera categoría, considera utilizar scripts que inicien y detengan aplicaciones de supervisión, como vmstat, iostat y netstat, en los hosts remotos. Estos scripts te permitirán obtener datos detallados del sistema de forma gratuita y con poco esfuerzo. Si no planeas utilizar todos los datos, guárdalos para futuros análisis.
• Archivado de archivos de registro: Cuando finalice la prueba, crea un solo script que recopile datos de un conjunto de máquinas y archive los archivos de registro en una ubicación central. Aunque pueda parecer tedioso, es recomendable llevar un registro detallado de cómo se procedió en la prueba, ya sea en un bloc de notas o en un archivo de Word. Esta documentación será invaluable cuando surjan problemas de rendimiento y se deba realizar un análisis.

Análisis de los resultados de la prueba de rendimiento

Si tienes una gran cantidad de datos para un conjunto de resultados, determina cuáles son esenciales para la vista de rendimiento que se está probando. Por ejemplo, si las transacciones que estás ejecutando tienen poco impacto en la base de datos, también deberías centrar tu análisis en este aspecto. Si estás probando la lógica de negocio en un conjunto de Enterprise JavaBeans, presta atención a ese componente de la aplicación distribuida. Es posible que debas agregar registros o lógica de perfilado adicional a la aplicación para obtener los datos necesarios, pero no dejes que estos afecten tus resultados. Siempre compara métricas de rendimiento comunes, como la máxima capacidad y la latencia mínima, entre las compilaciones. Realiza pruebas tanto con la lógica adicional como sin ella para ver si se produce algún deterioro.

Identificación de cuellos de botella del sistema

En un sistema informático distribuido, por lo general, hay una capacidad de rendimiento desigual entre todas las máquinas. Algunos procesos son más fáciles de escalar que otros, por lo que se pueden agregar más máquinas según sea necesario. Sin embargo, es importante determinar qué máquinas o procesos están limitando la capacidad de rendimiento general o agregando más latencia a una transacción.

En términos de latencia, si puedes registrar el tiempo que tarda en procesarse una transacción en cada etapa del sistema distribuido, puedes desglosar la transacción en una vista de series temporales que muestre gráficamente las áreas que consumen más tiempo y que podrían mejorarse. Luego, se pueden utilizar perfiles de código y de sistema para examinar estas áreas en busca de posibles optimizaciones.

Es la certificación suficiente para convertirse en un Oracle DBA

Para identificar los cuellos de botella de rendimiento, es necesario tener un buen entendimiento del comportamiento de cada componente del sistema distribuido. Algunos componentes, como los servidores web, pueden tener limitaciones de CPU o de E/S de red. Otros componentes, como las bases de datos y las colas, es probable que tengan limitaciones de E/S de disco. Algunos procesos de aplicación complejos pueden tener cuellos de botella en términos de CPU, E/S de disco, paginación de memoria o contención entre procesos, según el caso de uso. Si tu sistema consta de muchas máquinas y tiene una gran cantidad de transacciones, es posible que estés alcanzando las limitaciones del ancho de banda de tu red disponible. La única forma de saber cómo se comportará tu aplicación es evaluar la arquitectura fundamental y realizar pruebas confinadas.

Una vez que comprendas las limitaciones de cada componente en la aplicación, podrás identificar los cuellos de botella. Verifica las tasas de CPU usr/sys saturadas, la actividad de paginación en la capa de memoria virtual y el ancho de banda elevado de disco y red, o la alta utilización de CPU a la espera de E/S. Si no encuentras nada aquí, verifica las profundidades de la cola de ejecución (run-queue depths). Si las profundidades de la cola son grandes, indica que hay procesos limitados que pueden estar bloqueados o limitados por la CPU de alguna forma.

Algunos sistemas operativos te permiten examinar el estado del proceso y los detalles de la contabilidad, lo que brinda información sobre el tiempo que se pasa esperando la E/S o bloqueos del usuario. Otra posible causa de problemas podría ser la acumulación de colas de red. Si las colas comienzan a acumularse en una máquina, puede significar que esa computadora en particular, o la que está "hablando" con ella, está limitando el rendimiento total del sistema. Si no hay otra opción, puedes probar cada máquina por separado.

Benchmarks

A medida que las aplicaciones evolucionan hacia un modelo de servicio, se reduce el ciclo de vida de gestión del cambio y esto aumenta la importancia de la validación y benchmarking del rendimiento. Los benchmarks más valiosos incluyen conjuntos de resultados completos en un escenario real.

Comienza con los archivos de registro que has recopilado durante tus pruebas a lo largo de un período de tiempo. Introduce estos archivos de registro nuevamente en la aplicación lo más rápido posible y mide el tiempo que tarda en ejecutarse. Aunque no es un método infalible, es una manera rápida de obtener retroalimentación. Una opción aún mejor es abstraer el benchmark de los archivos de registro de la aplicación, lo que permite realizar pruebas más configurables y escalables.

Clasifica las solicitudes de los archivos de registro en grupos ponderados en función de la frecuencia de las solicitudes. Por ejemplo, si determinas que el 20% de las solicitudes a un servidor HTTP son para un programa CGI, el 30% son para páginas HTML y el 50% son para imágenes, puedes construir un benchmark con estos datos para determinar cómo se vería afectado el rendimiento del sistema si redujeras a la mitad el número de imágenes. Además, puedes investigar las distribuciones de probabilidad para cada grupo y luego desarrollar un programa para modelar dichas distribuciones.

Las ventajas y desventajas del outsourcing de TI offshore

Una vez establecido el benchmark, compáralo minuciosamente con las estadísticas del entorno de producción. La utilización del sistema y las mediciones de tiempo deben ser similares. Si tu sistema de prueba no tiene la robustez de tu entorno "en vivo", puedes desarrollar multiplicadores teóricos de escalabilidad.

Darse cuenta de que las pruebas de rendimiento son un proceso rico en procedimientos es quizás el primer paso para simplificarlo. Las recompensas obtenidas mediante el tiempo invertido en la preparación de las pruebas y el desarrollo de herramientas para automatizar y simplificar el proceso valdrán la pena.

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre CXO, allí encontraras muchos artículos similares a Cómo realizar un análisis de rendimiento para sistemas informáticos distribuidos , tenemos lo ultimo en tecnología 2023.