menu_superior

Para qué sirven las pruebas de rendimiento (IV). Pruebas de dimensionamiento

Este post forma parte de una serie sobre pruebas de rendimiento. Aquí puedes acceder al tercer post de la serie y aquí a todos los posts publicados hasta ahora.

Pruebas de dimensionamiento Siempre que pensamos en poner en producción una nueva aplicación pensamos en la manera en la que vamos a organizar la construcción del software, en las metodologías, en las herramientas, con suerte en las pruebas… Dependiendo de la experiencia que tenga cada uno en estas situaciones entrará más o menos en detalle sobre todo lo que rodea a la salida a producción de un producto software. Algunos, pocos, pensarán en que en el argot se conoce como “el hierro”: la infraestructura, las comunicaciones, estrategias para distribuir los servidores, balanceadores, etc… Digo pocos por que esta preocupación solo está en la mente de los integrantes del equipo de Sistemas (aka Producción). Es rarísimo que un jefe de proyecto tenga nociones de estas materias. Más allá de las bases de datos se extiende una nebulosa donde nadie se atreve a internarse y de la que solo hay un esquema de red que suele estar desactualizado (por que nadie se atreve a internarse) o copipegado de otra aplicación que alguién montó hace tiempo.

La primera idea que quiero esbozar en este post es que “el hierro” también existe. Mejor aún, existe y es parte esencial del sistema por que será el soporte de nuestro software. Así las cosas, debemos tener información suficiente del tipo de infraestructura que vamos a tener antes (sí, he escrito ANTES) de meternos a diseñar el software. El hecho de que la infraestructura dependa de otro departamento con personas tan especializadas como este no es motivo para olvidarnos de este tema. Mi postura es que es necesario hilo directo con sistemas, estar muy cerca de ellos por que la experiencia me dice que es mucho más fácil ajustar el software y el hardware si desarrollo y producción están alineadas.

¿Por qué pruebas de dimensionamiento?

Este paisaje justifica que el equipo de pruebas, el de desarrollo y el de sistemas trabajen juntos. Me parece lo más adecuado, teniendo en cuenta que el sistema de información en el que vamos a trabajar está formado por hardware y por software de manera indivisible y las pruebas se plantean sobre el sistema completo. De otra manera podemos hacer las pruebas que queramos: funcionales, de rendimiento y de cualquier otro tipo, pero no estaremos eliminando riesgos de fallos por incompatibilidades o interacciones imprevistas. Es necesario saber cómo se comporta la infraestructura elegida con el software que vamos a construir en escenarios de alta carga de trabajo, no vale aquello de “en mi máquina funciona” o “en el servidor de desarrollo funciona”. Tiene que ser el software y el hardware que absorberán esa carga de trabajo los que demuestren que pueden trabajar juntos, cómo deben hacerlo y hasta donde llega cada uno. Las pruebas nos darán información con la que podremos ajustar o dimensionar los elementos como sigue:

  1. Software del sistema. El dimensionamiento del software afecta a la compatibilidad de los controladores entre sí y con la infraestructura. También afecta a parametros típicos de configuración como  cachés, pooles de conexiones, paginación de memoria y disco, hilos de ejecución en CPU, etc.
  2. Infraestructura del sistema. Este es el mayor beneficiario por que gracias a las pruebas de dimensionamiento sabremos qué volumen de peticiones es capaz de manejar un servidor, hasta que nivel de carga podemos llegar sin colapsar el sistema, cual es el nivel mínimo de infraestructura necesario para mantener un tiempo de respuesta, qué características y prestaciones le exije el software a las máquinas… Podemos extraer de las pruebas toda la información necesaria para dimensionar nuestro sistema en distintos supuestos, calculando los costes de cada uno y elegiendo o estableciendo compromisos entre inversión y rendimiento.

La idea de fondo es que las pruebas de dimensionamiento sean algo más que unas pruebas: una simulación que nos permite prever el comportamiento de nuestro sistema de información y ajustar la inversión a la necesidad real.

¿Qué riesgos eliminamos con estas pruebas?

Hay veces que la estimación, sin pruebas, se hace a bulto y dejamos en manos del azar el correcto funcionamiento del sistema. Todo lo que no sea hacer unas pruebas de dimensionamiento previas a la salida a producción implica los siguientes riesgos:

  1. Desajustes entre el software y  el hardware. Obviamente si nuestro hardware y nuestro software no se llevan bien, con estas pruebas no podrán esconderlo por más tiempo. Esto nos permitirá conocer la magnitud del problema y pensar en la solución que mejor lo resuelva, puede ser tan simple como un cambio de versión de un controlador o cambiar una linea en un archivo de configuración.
  2. Incremento de costes. Yo creo que no hay que llevar mucho tiempo trabajando en proyectos de TI para reconocer la situación: después de sangre, sudor y horas extras lágrimas, sale el sistema a producción y su rendimiento no es el esperado, la aplicación es lenta, los usuarios no están contentos y los niveles ejecutivos están dispuestos a hacer lo que sea para ponerle remedio a esta falta de rendimiento. Como parece que faltan recursos, se amplia la infraestructura con una ampliación de la inversión… Y seguimos igual o no mucho mejor, y se vuelve a invertir en recursos de infraestructura… al final hay un monstruo con capacidad de superordenador que no puede con aplicaciones de gestión corrientes y molientes. Las pruebas pueden evitar este desastre y ahorrar problemas y dinero a la hora de elegir y dimensionar la infraestructura necesaria…

La verdad es que no es un tipo de prueba que hagamos con frecuencia y para mí tiene una importancia grande a la hora de sacar sistemas a producción. Hoy lo vamos a dejar aquí por que los detalles alargarían este, ya de por sí largo, post. En un futuro no muy lejano habrá que volver sobre este tema para entrar en algunos detalles. Mientras tanto, podeis usar los comentarios para contar experiencias, hacer consultas o resaltar cualquier cuestión que penséis que es importante sobre las pruebas e dimensionamiento.

Pincha aquí para ir al capítulo anterior y aquí para ir al siguiente

, , , , , , ,