menu_superior

SI VA LENTO METE MÁS HIERRO

si va lento mete más hierroEn todo el tiempo que llevo trabajando en temas de pruebas de software, una de las excusas justificaciones para no hacer pruebas de rendimiento que más veces he recibido y que más perjudicial me parece es la que aparece en el título de este post, “Si va lento mete más hierro”. La he utilizado como título por que creo que resume perfectamente la actitud y el lenguaje de aquellos que consideran a las pruebas como actividad que no mejora el aplicativo y que no es rentable, es decir, aporta menos valor de lo que cuesta. Me gustaría entrar a analizar en profundidad estos mitos para desmentirlos y empezar a dejarlos atrás cuanto antes.

SOLUCIONES INFORMALES A PROBLEMAS DE BAJO RENDIMIENTO

Meter más hierro es un problema en sí mismo por que supone gastar dinero en mitigar un problema del que no sabemos la causa. Además, meter más hierro tampoco es un proceso formal, con lo cual tampoco sabemos cuántas veces tendremos que hacerlo ni cada cuanto tiempo. Es decir que optamos por una supuesta solución totalmente a ciegas, cuando lo más fácil sería hacer un pequeño ciclo de pruebas de rendimiento que nos permita aislar las causas de la pérdida de rendimiento.

Otro cabo suelto es cómo determinar cuanto más hierro hay que meter… Esto tampoco es fácil. No podemos definir con claridad si con un servidor más valdría, si se necesita un procesador más, o si con 16 Gb de memoria será suficiente. El origen de los problemas de rendimiento en los sistemas viene por tres vías: por los componentes hardware (inadecuados o defectuosos), por la configuración de controladores (drivers, conexiones, pila de memoria, paginación de memoria, cachés…) y, en último extremo, por la gestión que el software del aplicativo hace de los recursos. Cada uno de estos problemas se tratan de manera diferente pero tienen algo en común: es necesario un análisis de las causas para diseñar la solución adecuada en cada caso.

LA EXCEPCIÓN

Hay un caso en el que este tipo de solución “informal” es una manera ingeniosa y ágil de salvaguardar el rendimiento del sistema. En aplicativos que funcionan razonablemente bien, que tienen un rendimiento y una demanda estable y sufren picos muy puntuales. Se me ocurre el ejemplo de una web de comercio electrónico en rebajas o de venta de entradas para un concierto con altísima demanda. En estos casos meter más hierro temporalmente es aconsejable y su gestión puede ser muy rentable si se utilizan plataformas cloud como AWS de AmazonServidor cloud de Arsys o Acens.

ALGUNAS IDEAS

Definir el tiempo de respuesta límite, así como la carga de trabajo máxima soportada por el sistema. No es lo mismo un tiempo de respuesta de 10 segundos con 100 usuarios concurrentes que con 500 usuarios.

Hacer pruebas de rendimiento diagnósticas para localizar el problema.

Establecer una estrategia de mantenimiento a largo plazo: Hacer pruebas de rendimiento antes de sustituir componentes o migrar controladores.

Repetir las pruebas cada 6 meses y comparar resultados para registrar y gestionar la evolución del rendimiento del sistema.

, , ,

Comments are closed.