h1

El wait-based tuning: un ejemplo de la vida real

01/30/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks

La semana pasada vimos qué es la Administración del Desempeño de Aplicaciones (APM) y los fundamentos del wait-based tuning (WBT). En esta parte la intención es demostrar cómo opera esta metodología con un ejemplo de la vida real.

1. Arquitectura y configuración

Para este ejemplo utilizaremos una arquitectura web estándar:


Una arquitectura web estándar.
[Click en imagen para ver versión más grande]

Podemos describir la arquitectura en función del tier donde nos encontremos:

  • Hardware. Seis servidores con arquitectura RISC de dos procesadores por socket a 1.5 GHz c/u; 4 GB en RAM y un disco duro de 73 GB de espacio. Dos servidores balanceados por cada tier.
  • Front End. Dos servidores cada uno con una instancia de un servidor web (Apache Http Server) y configuración inicial de 150 threads activos.
  • Middle End. Dos servidores con dos instancias lógicas del servidor de aplicaciones (Sun Application Server), cada una con 50 threads, 30 conexiones a base de datos, un cache asignado para 500 Entity Beans y 1 GB de memoria asignada al heap de la Máquina Virtual de Java.
  • Back End. Dos servidores con un motor de base de datos como parte de un Oracle 10g RAC configurado. En el diagrama no se incluyen el disco externo ni el balanceador de alta disponibilidad – requisitos de dicha instalación – para efectos de simplicidad.
  • Firewalls. Los equipos se encuentran separados en dos zonas de seguridad: una DMZ para el front end y una intranet segura para los equipos de middle y back-end. La única forma de acceder a los equipos del back end es mediante los firewalls y todos los puertos y servicios no esenciales han sido deshabilitados.
  • Conectividad. El balanceo de cargas es implementado por dos balanceadores dedicados específicamente para este fin; la configuración de ambas capas es activo-activo (es decir, ambos nodos están funcionando con balanceo de carga, al contrario de una configuración activo-pasivo donde uno funciona y el otro entra en acción en caso de falla).

2. Diagnóstico

De acuerdo al plan original, esta plataforma está diseñada para un ambiente de producción mediano, con la capacidad para 2,000 usuarios concurrentes. Para validar qué tanto tuning es necesario hacer, se realizan las pruebas de desempeño, carga y estrés: Se genera una prueba base con 1,000 usuarios concurrentes durante 20 minutos y a partir de dichos 20 minutos, se agregan 50 usuarios cada 5 minutos hasta llegar a 2,200. Sin ahondar mucho en cómo corre la prueba, después de los 2,200 usuarios los servidores empiezan a congelarse y a generar errores OutOfMemoryError.

El resultado de las pruebas proporciona el siguiente diagnóstico:

  • Existe un alto desperdicio de recursos, pues bajo estrés los servidores de aplicaciones y base de datos llegan a un máximo de uso de CPU del 20% y 40% respectivamente.
  • La caída del sistema se debe a falta de memoria, no CPU. Esto implica falta de tuning de pools, caches y heap del JVM.
  • La falta de tuning puede comprobarse al verificar que el pool de conexiones a base de datos y threads de procesamiento de peticiones del application server están siendo utilizados al 100%; quedando pendientes de procesar (en espera) 10 threads y 20 peticiones en promedio.
  • El Cache Hit Ratio de Entity EJBs tiene una tasa del 40%, es decir, que de 100 peticiones a la capa de persistencia, 60 tienen que ir a la base de datos y sólo 40 se extraen de memoria.

El diagrama mostrado a continuación muestra esquemáticamente los resultados de las pruebas:


Los resultados de las pruebas de diagnóstico de desempeño.
[Click en imagen para ver versión más grande]

3. Iteración 1

Enfocándonos en la última tina, cuya capacidad está siendo desperdiciada, analizamos el punto donde las peticiones esperan demasiado: Los pools y caches de recursos del Application Server. Por lo tanto, incrementamos los hilos de ejecución y conexiones a base de datos para aumentar el uso de CPU de ésta. Entonces re-configuramos y volvemos a correr el batch de pruebas de volumen para ver los resultados. Los cambios de configuración y sus efectos son los siguientes:

Cambios

Efectos

Threads de ejecución +50
Conexiones BdD +30
Entity EJB +500

CPU (Web Server) 75%
CPU (App Server) 50%
CPU (BdD) 70%
Entity EJB CHR 80%

Básicamente, al duplicar los pools y caches de recursos, incrementamos el uso de CPU de la plataforma en su conjunto en poco menos del doble. Esto se puede ver en el siguiente diagrama:


Los resultados de la primera iteración del tuning.
[Click en imagen para ver versión más grande]

Como puede verse, todavía no llegamos al óptimo pues aunque ya tenemos 80% de Cache Hit Ratio de Entity EJBs, todavía persiste un desperdicio de CPU y un excedente de peticiones en espera de ser atendidas.

4. Iteración 2

Incrementamos 20 hilos de ejecución y otras 30 conexiones a base de datos, esperando alcanzar el uso óptimo de CPU de esta última…

Cambios

Efectos

Threads de ejecución +20
Conexiones BdD +30

CPU (Web Server) 85%
CPU (App Server) 40%
CPU (BdD) 95%
Peticiones Pendientes 40

…sin embargo llegamos a un punto de saturación con 95% procesador. También mejoró el uso del Web Server, pero la saturación de la Base de Datos hace que en el Application Server se queden más peticiones en espera (¡casi el doble!). Esto puede verse en el siguiente diagrama:


Los resultados de la segunda iteración del tuning
(Una saturación de la Base de Datos)
[Click en imagen para ver versión más grande]

Por lo tanto, tendremos que disminuir un poco la capacidad de dichos recursos.

5. Iteración 3

Al disminuir los hilos de ejecución y conexiones a base de datos a 100 y 75 respectivamente, incrementamos notablemente el desempeño de nuestra plataforma:

Cambios

Efectos

Threads de ejecución -20
Conexiones BdD -15

CPU (App Server) +80%
CPU (BdD) 85%%
Threads pendientes de ejecución 5
Peticiones pendientes de ejecución 10

Como puede verse en el diagrama más abajo, prácticamente ya estamos hechos: sólo falta disminuir un poco el flujo de entrada de y hacia el application server para no tener más peticiones o hilos pendientes de ser atendidos.


Los resultados de la tercera iteración del tuning.
[Click en imagen para ver versión más grande]

6. Iteración 4

Así entonces, disminuimos los hilos de ejecución de y hacia el application server por 10 y 25 respectivamente. Volvemos a correr nuestro set de pruebas y… ¡voila! alcanzamos el tuning perfecto:


Los resultados de la tercera iteración del tuning.
[Click en imagen para ver versión más grande]

Con un uso de CPUs de aproximadamente el 85% (excelente número bajo pruebas de estrés), pools de conexiones a base de datos e hilos de ejecución a 95% y 90% de capacidad respectivamente y cero peticiones pendientes de procesar, hemos alcanzado un buen nivel de tuning. Los siguientes pasos serían la optimización sobre la base de datos y la aplicación misma, si no es que ya han sido realizados.

Conclusiones

Como hemos podido ver en los dos últimos posts, la APM nos permite generar arquitecturas siempre tomando en cuenta el desempeño final de nuestra solución; formando parte del ciclo de vida de desarrollo y puesta en producción obteniendo resultados en términos cualitativos y cuantitativos.

Por otro lado, el modelo Wait-Based Tuning nos da un marco de referencia para desarrollar pruebas de desempeño, carga y estrés, donde cualquier refinamiento debe empezar por los niveles de ejecución más altos (la aplicación) y finalizar con los más bajos (el hardware).

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: