h1

De Performance and Tuning

01/25/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks

Entre compañías con un ingreso mayor a US$1,000 millones, cerca del 85% ha experimentado incidentes de degradación de desempeño en sus aplicaciones.

— Jean-Pierre Garbani
Vicepresidente
Forrester Research

Como parte de este nuevo año me tocó, entre otras cosas, hacer un cursito de performance and tuning para el personal clave de desarrollo y operaciones de nuestro cliente. Ya tengo casi todo terminado, aunque me faltan algunos ejemplos y láminas adicionales por si alguno de mis estudiantes se pone sus moños. Si todo sale bien, tendré que darlo para dos grupos de 5 a 7 personas durante dos semanas. Por lo tanto, dejo aquí un resumen de mi presentación y que me sirve muy bien de acordeón para salir bien librado de esta tarea que me ha sido encomendada. Empezamos:

¿Por qué preocuparnos por el desempeño? Más allá de la productividad perdida para apagar el bomberazo o que las empresas le paguen a sus empleados por no hacer nada y esperen a que sus aplicaciones vuelvan a operar, o que el propio tiempo fuera de línea (downtime) pueda generar pérdidas en millones de dólares, un tema preocupante en estos tiempos de competencia destructiva es la pérdida de de credibilidad ante el cliente y la disminución de su confianza ante un evento de degradación del desempeño en las aplicaciones; sobre todo aquellas que pertenecen a la categoría del e-commerce.

Por otro lado, como es bien sabido en esta industria, el costo para corregir un problema crece exponencialmente conforme al tiempo, de acuerdo al momento durante el ciclo de vida de desarrollo en que es descubierto:

Una elección incorrecta durante la fase de análisis puede implicar sólo la modificación de documentos si es detectada a tiempo…

… pero si el mismo problema se descubre hasta la puesta en producción, puede representar un cambio radical en la arquitectura e incluso empezar desde cero.

Sin embargo, ¿Cómo podemos definir la capacidad máxima de nuestra solución? ¿Cómo podemos asegurar que el desempeño de una aplicación sea de acuerdo a lo planeado?

La Administración de Desempeño de Aplicaciones

La Administración de Desempeño de Aplicaciones (Application Performance Management – APM) es una disciplina de la que se desprenden algunas metodologías que aseguran el máximo desempeño de una plataforma a lo largo del ciclo de vida de desarrollo y despliegue. Sus objetivos principales son:

  • Anticipar requerimientos por recursos.
  • Identificar dificultades mientras todavía son problemas potenciales.
  • Implementar la solución apropiada antes de que ocurra una falla.

Nota: dos guías/metodologías de administración e ingeniería de desempeño que recomiendo ampliamente son:

La mayoría de las metodologías de administración del desempeño incluyen desde la definición de la arquitectura condiciones de éxito en función del desempeño que forman parte de los casos de uso de la solución que se está diseñando. Dichas condiciones son conocidas como Service Level Agreements – SLAs y deben incluir parámetros cuantitativos del desempeño esperado de la solución. Por otro lado – y esto es muy importante – dichos parámetros deben ser negociados entre el cliente o usuario final y el arquitecto, para poder filtrar requerimientos poco realistas (por ejemplo: quiero que mis 2 PCs soporten una carga de 5,000 usuarios concurrentes).

Por otro lado, es necesario enseñar a los desarrolladores a probar sus componentes de forma unitaria e integral, incluyendo en dichas pruebas no sólo la funcionalidad, sino también el uso de memoria y eficiencia de algoritmos. Esto se logra mediante tres simples técnicas de análisis:

Nota: estas técnicas están enfocadas a Java/J2EE, pero son aplicables a cualquier lenguaje de programación.

  • Memoria: uso del memory heap y garbage collection.
  • Perfil de código: Eficiencia de los algoritmos.
  • Análisis de cobertura: Qué porciones del código son más ejecutadas que otras.

Así mismo, durante las iteraciones del desarrollo es muy importante que el equipo de QA valide que los casos de uso y pruebas incluyan el SLA correspondiente y que los desarrollos cumplan satisfactoriamente con dichos SLAs; si un componente o módulo no cumple con todos los requerimientos debe regresarse al equipo de desarrollo para su corrección o si se ha detectado que es costoso en términos de tiempo o recursos, notificar inmediatamente al administrador de proyectos y arquitecto para su negociación con el cliente.

Finalmente, previo a la liberación a producción, es necesario comprobar que la solución cumple con los SLAs bajo la carga proyectada. Esto es logrado mediante una evaluación de capacidad y la mayoría de las metodologías proporcionan pasos generales para su implementación:

  • Desempeño bajo carga esperada.
  • Punto en que los SLAs inician su no conformancia.
  • Conforme aumenta la no conformancia con los SLAs, cuál es el patrón de degradación.
  • Cuál es el punto de saturación de la aplicación (cero conformancia con los SLAs).

Hablando en términos de ingeniería, estos puntos son los objetivos de las pruebas de desempeño, carga y estrés:


La curva ideal de volumen contra el tiempo: Conforme aumenta la carga, mejora el rendimiento debido al mayor número de hits en los caches y pools de objetos; al llegar a la capacidad máxima el desempeño permanece estático; al sobrepasarla comienza la degradación del desempeño de forma suave pero constante.

El resultado de estas pruebas debe permitir al arquitecto definir dos puntos:

  • La capacidad máxima en términos de calidad en el servicio (throughput, response time) del sistema (o lo que es lo mismo: hasta qué volumen de carga puede soportar esta plataforma sin que se desesperen los usuarios u ocurra un crashdown).
  • Planear los componentes que serán necesarios para un crecimiento vertical (esencialmente, bajo qué condiciones deberán integrarse más memoria, otro balanceador o un servidor adicional).

El APM desde el punto de vista ingenieril

Una cosa es planear el tuning de la plataforma antes de liberarla a producción y aplicar un monitoreo de ésta para asegurar que el capacity planning fue correctamente implementado; otra y muy diferente es cómo hacer dicho tuning.

Tomando las mejores prácticas de los procesos de performance and tuning – P&T ejecutadas por algunos proveedores de middleware como Sun Microsystems, IBM y Oracle es posible definir tres grandes guías que nos ayudarán a realizar un P&T de forma efectiva:

1. Cualquier aplicación empresarial emplea un modelo de ejecución por capas

Como se ve en el siguiente diagrama:


Las capas de servicios de una aplicación empresarial.

Cuando se realice el tuning de una plataforma, siempre se debe comenzar por la aplicación; una vez que la misma haya sido razonablemente optimizada se puede proseguir con la capa de servicios – el application server – y así sucesivamente hasta la capa de hardware. La razón principal es la dificultad de optimización por capa: mientras buenas técnicas de programación y adherencia a patrones de diseño deberían bastar para hacer que una aplicación en Java funcione como debería, optimizar hardware o el sistema operativo pueden ser toda una hazaña (por no decir que el recurso especializado puede costar una fortuna).

Con el modelo de capas en mente, se desprende el siguiente punto:

2. Debe existir visibilidad sobre todos los componentes tecnológicos de la plataforma

Esto incluye:

  • Cada sistema operativo donde los servicios se están ejecutando.
  • Cada elemento tecnológico de las capas del modelo de ejecución (por ejemplo, frameworks).
  • El desempeño de las tecnologías que dan soporte a la aplicación en ambientes de ejecución no J2EE (por ejemplo, un web service corriendo en .NET).
  • Dependencias externas tales como una base de datos o sistemas de información empresarial (EIS) que puedan encontrarse fuera del entorno de red local.
  • El comportamiento de la red de comunicaciones entre la aplicación y sus servicios.

Finalmente, aunque existe toda una teoría e infinidad de metodologías del tuning basadas en tiempos de respuesta, flujo de información y demás métricas de desempeño, existe un modelo alterno muy sencillo y que es posible ejecutar sin demasiados problemas sobre una plataforma distribuida:

3. El modelo wait-based tuning (WBT)

Dicho modelo fue desarrollado por Oracle para simplificar el tuning sobre sus bases de datos y es soportado nativamente por éstas desde la versión 9i. Presentado por primera vez en 1998 en el Oracle Open World (aquí está el outline de la presentación), es la metodología estándar que emplean en este tipo de servicios (Ver en este documento PDF una descripción un poco más técnica con enfoque en tuning de bases de datos). A grandes rasgos, el WBT está basado en optimizar aquellos puntos a lo largo de la plataforma donde una petición tenga que esperar para ser procesada. Es decir, cuando una petición llega del cliente hacia la plataforma, en algún punto tendrá que ser encolado para esperar a ser procesado (después de todo, un CPU no puede procesar 5,000 usuarios al mismo tiempo, ¿verdad?). En el siguiente diagrama se ve un poco más claro este concepto:


Los puntos de espera de una plataforma web.
[Click en imagen para ver en tamaño original]

Así entonces, tenemos que realizar el tuning sobre los siguientes componentes de la infraestructura:

  • Colas de procesamiento de peticiones.
  • Pools de hilos de ejecución.
  • Pools de recursos (por ejemplo, conexiones JDBC) y componentes J2EE (como el pool de EJBs)
  • Caches de objetos.

El proceso de tuning implica monitorear estos elementos y detectar su punto de saturación; luego disminuimos la capacidad de los puntos de espera precedentes para facilitar sólo la carga máxima sobre el punto de espera que estamos analizando y al final aumentamos o disminuimos la capacidad del web server para reenviar a los "usuarios excedentes" a la página de error. La mejor analogía que se me ocurre es la de las llaves de agua en cascada siendo cada contenedor una tina: si el flujo es demasiado la tina se derrama y si es insuficiente la tina queda vacía.

La semana próxima me refinaré un ejemplo del WBT para que sea más fácil de entender y no se quede como algo abstracto. No lo dejo aquí porque alargaría mucho el post y además, así como lo estoy viendo, implica generar una buena cantidad de diagramitas en Visio que sí se llevan su tiempo. También es conveniente que incluya los "Tips que todo software engineer debe saber para mejorar el performance de su application server y Java Virtual Machine", y se vería algo chispa si lo incluyo en este momento. A ver cómo me va Guiño.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: