|
3.
PRUEBAS DE CARGA Y ESCALABILIDAD.
El propósito
de las pruebas de carga y escalabilidad es asegurar que la aplicación
tendrá un buen tiempo de respuesta durante los picos de uso.
También se puede evaluar cómo la aplicación se
comportará a lo largo del tiempo (conforme el sitio Web contenga
cada vez más información en la base de datos). Para comenzar
a probar, escriba algunos guiones de prueba que llenen la base de datos
con una cantidad promedio de datos. Ejecute las pruebas de rendimiento
y mida el tiempo de respuesta. A continuación, llene la base
de datos con una cantidad extremada de datos (3 o 4 veces más
datos de los que se prevee que haya en 3 años). Ejecute de nuevo
las pruebas de rendimiento. Si los tiempos de respuesta son significativamente
mayores para la segunda prueba, entonces algo falla.
Para ejecutar
las pruebas de rendimiento, deberá simular el uso del servidor
con diferentes cargas. Como regla general, yo simulo carga baja (de
uno a cinco usuarios concurrentes), carga media (de 10 a 50 usuarios
concurrentes) , carga alta (100 usuarios concurrentes) y carga extrema
(1000 o más usuarios concurrentes). Nótese que esos números
son arbitrarios y dependen de las necesidades del negocio. Además,
simular 10 usuarios concurrentes con software de pruebas de carga no
es representativo de 10 personas, ya que cada “robot” en
la prueba de carga puede esperar sólo milisegundos antes de acceder
de nuevo al servidor. Por lo tanto, usar un probador de carga para simular
10 usuarios es probablemente representativo de los comportamientos de
navegación en el web de 30 o 40 personas.
Una vez ha
probado estos tres niveles de carga, puede comparar tiempos medios de
respuesta para ver si su sistema es escalable, es decir, si el tiempo
de respuesta aumenta linealmente.
4.
INTERPRETANDO LOS RESULTADOS.
La parte
divertida de este proceso es interpretar los resultados de las pruebas
de carga. Examinemos algunas de las diferentes posibilidades:
-
El
tiempo de respuesta aumenta demasiado cuando la
base de datos se llena mucho
El tiempo de respuesta no debería aumentar demasiado si se pasa
de una base de datos con 100 filas en sus tablas a una con 50,000 filas.
La tecnología de indexado de bases de datos hace que hallar una
fila en una tabla tarde unos cuantos milisegundos, incluso si hay cientos
de miles de filas. Por lo tanto, si el tiempo de respuesta aumenta mucho
después de pasar de una base de datos de tamaño moderado
a una de tamaño extremo, entonces probablemente aún no se
han indexado las columnas apropiadas.
-
El
tiempo de respuesta aumenta exponencialmente cuando
aumenta la carga
Si el sistema se vuelve inutilizable conforme se aumenta el número
de usuarios concurrentes, entonces el sistema no es escalable. Interpretar
estos resultados es difícil pues el problema podría ser causado
por el hardware, la configuración de despliegue, la arquitectura,
etc. Asegúrese de que observa los recursos del servidor durante
las pruebas:
-
Observe
los requerimientos de memoria.
- Observe
el uso de CPU. Si la CPU se usa demasiado, se necesita
un procesador más rápido o más
procesadores. Si la CPU se usa poco, entonces probablemente
el problema esté en la entrada/salida. Compruebe
las conexiones de bases de datos, el número
de threads (hilos) que se ejecutan y la configuración
de la red en las máquinas de prueba.
Si el problema
no se resuelve después de comprobar la configuración,
de verificar que la lentitud no se debe a un cuello de botella del hardware
y de revisar rápidamente la arquitectura buscando código
para optimizar, es el momento de ejecutar un perfilador de código.
|
