Capacity planning
El capacity planning es un procedimiento iterativo cuyo objetivo es optimizar la capacidad de un sistema de información. Algunos dicen que es un arte, aunque para nosotros, gracias a nuestra experiencia, nos resulta en un proceso totalmente bajo contol.
Este proceso es conveniente realizarlo 1-2 semanas antes del pase a producción de una aplicación. Nosotros consideramos que es fundamental contar con este margen en las planificaciones y realizar este proceso antes. Es evidente que también podemos realizarlo después del pase a producción. Pero si la aplicación no aguanta la carga, el daño ya está hecho.
Nuestro proceso de capacity planning comienza con la definición de objetivos de rendimiento a alcanzar. Esta parte es fundamental, pues sin unos objetivos claros nunca sabremos si hemos optimizado lo suficiente. Estos objetivos deben expresarse en términos de número de usuarios concurrentes (incluso diferenciando horas punta y horas valle), tiempos de carga, tiempos de respuesta, etc. Pueden medirse tanto en el lado del servidor, como en el lado del cliente (experiencia del usuario).
Una vez tenemos claros los objetivos, empezamos la optimización con el sistema operativo, a nivel de kernel, y siempre siguiendo las recomendaciones del fabricante.
A continuación procedemos a realizar la optimización de la base de datos, en varios frentes:
- Diseño: entidades, índices, etc.
- Optimización de E/S a disco: buffers, etc.
- Checkpointing: volcado de cachés sucias a disco.
- Tuning específico de la base de datos, según el fabricante.
Posteriormente realizamos una optimización de la máquina virtual (JVM). Esta es una de las partes a las que se suele prestar menos atención, pero que en función del entorno, optimizar una configuración por defecto puede suponer un incremento del throughput general en hasta un 80%. En este punto hablamos de la optimización del heap (tamaños, áreas generacionales, etc.), algoritmos de recolección de basura, etc.
Después pasamos a optimizar el servidor de aplicaciones, en particular, los parámetros que en éste se pueden definir. Nos referimos a colas de threads, pooles de conexionesa bases de datos, cachés de sentencias SQL, etc. Una mala configuración aquí puede llegar a provocar hasta denegaciones de servicio.
Seguidamente monitorizamos y optimizamos tanto el disco como la CPU de las máquinas que alojan el servidor de aplicaciones, descartando que el cuello de botella se produzca en la base de datos (queries, índices, ORDER BY, etc) o en el servidor de aplicaciones (trazas de JMS, logging, ...).
El siguiente paso es monitorizar la red, descartando que sea ahí donde esté el cuello de botella (tráfico multicast, timeouts en routers, etc).
El último paso consiste en buscar el cuello de botella en el código de la aplicación haciendo profiling.
En todos estos pasos, el procedimiento consiste en:
- Realizar alguna modificación.
- Lanzar pruebas de carga.
- Monitorizar el rendimiento, y tomar una decisión: o descartar que el problema esté en esa capa y pasar a la siguiente, o volver a realizar otra modificación.
Para poder realizar este proceso, es fundamental la existencia de:
- Pruebas de carga: completas y reales. Deben probar los casos de uso más utilizado, y los más críticos en cuanto al rendimiento.
- Herramientas de monitorización. Es evidente que sin estas herramientas no podemos saber qué está pasando.