Consideraciones para la realización de pruebas de escalabilidad

Las pruebas de escalabilidad se utilizan para determinar si la aplicación permite acomodar a un número creciente de usuarios mediante la adición de hardware, sin tener que modificar el software. Durante su ejecución, no se busca realmente obtener cifras acerca de cuantos usuarios pueden subirse a la plataforma, sino que establecer un patrón de escalabilidad para el sistema. Esta información permite determinar el número de usuarios que pueden ser soportados, con un desempeño aceptable, para un entorno definido.

Los números obtenidos de una prueba de desempeño sólo son relevantes para un sistema específico, en un ambiente específico. Esto implica que los benchmarks que se obtienen de la industria no son más que una referencia, que inexcusablemente debe ser complementada con actividades de la propia organización para reducir el riesgo de salir a producción con niveles de servicio deficientes. 

En un sistema ideal, el desempeño no debiera degradarse a medida que se agregan usuarios, sino que debiera mantenerse constante hasta que la máquina se sature, punto en el cual se debiera apreciar una fuerte degradación del desempeño. Los gráficos de tiempos promedio de respuesta versus usuarios trabajando debieran mostrar una forma que se denomina “palo de hockey”.

La realidad, como siempre, es algo menos ideal, y lo que generalmente se encuentra es una figura como la siguiente:

En la figura se aprecia una leve pendiente, que implica que el sistema se está degradando a una tasa que puede ser aceptable o no dependiendo de la organización. En sistemas intensivos en utilización de recursos compartidos, la leve pendiente se podría ser, por ejemplo, una consecuencia de la contención de recursos que se pueda estar originando al llegar nuevos usuarios. 

Definición de escenarios para pruebas de escalabilidad
Los pasos para desarrollar una prueba de escalabilidad son los siguientes:

1. Definir un escenario realista 
2. Grabar el escenario 
3. Correr el escenario para simular usuarios concurrentes, simulando cada vez más usuarios 
4. Cuando el desempeño se degrada a tal punto que no permite usar aceptablemente el sistema, se ha encontrado el máximo número de usuarios. 

Para la definición del escenario, se deben tener las siguientes consideraciones:

• No se trata de una prueba funcional, por lo que se debe trabajar con escenarios de probable uso frecuente en producción y no en función de escenarios que constituyan condiciones de borde. 
• Sin embargo, los escenarios deben ser diversos, no deben acotarse por ejemplo siempre a una operación de consulta, sino que deben simularse múltiples casuísticas de ingreso, borrado, consulta, navegación, etc. 
• Se debe establecer un tiempo de respuesta promedio aceptable. Se recomienda que este tiempo se establezca en función del tiempo que se demora en ejecutare el escenario para un solo usuario. Por ejemplo, si para un sistema X, se ejecuta el escenario de prueba con solo un usuario y da como resultado un tiempo medio de respuesta de 300 ms, podría definirse el tiempo de respuesta promedio aceptable para una ejecución con múltiples usuarios como el doble, 600 ms. 

Escenarios de pruebas de memoria restringida
Las pruebas de memoria restringida se utilizan para determinar la cantidad de memoria consumida por usuario. Se realiza forzando a la memoria a ser un cuello de botella mediante su saturación. De esta manera, cuando el servidor se satura, se sabe que la causa es la memoria. Para realizar este tipo de pruebas, se debe contar con un poder de procesamiento sustancialmente mayor a la memoria disponible.

A modo de ejemplo, si corriendo el sistema con 4 CPUs (asumiendo que esto sobra) y 1 GB de RAM, se satura con 50 usuarios, el consumo medio de memoria por usuario se puede establecer en 20,48 MB/usuario. 

Escenarios de pruebas de CPU restringida
La segunda prueba que se puede hacer es para determinar cuantos usuarios por CPU pueden atenderse. Para esto se realiza la prueba con las condiciones revertidas: mucha RAM y poco CPU.

A modo de ejemplo, si corriendo el sistema con 1 CPU y 4 GB en RAM (sobre la base que esta sobra para lo que se desea realizar), el sistema colapsa a los 50 usuarios, se puede concluir que el sistema puede atender 50 usuarios por CPU. 

Ejecución de escenarios para pruebas de escalabilidad
Para la ejecución de los escenarios se deben tener en cuenta las siguientes consideraciones:

• Los escenarios se deben correr sobre condiciones que simulen la realidad. Aunque esto suene obvio, muchas veces se comete el error de simular la realidad sólo a nivel de infraestructura y middleware, y no se consideran otros factores como el estado probable del sistema tras el paso del tiempo. Por ejemplo, no se deben correr pruebas de escalabilidad sobre una base de datos vacía, sino que esta debe tener datos que simulen el volumen que tendrá la base de datos productiva dentro de uno o más años. 

• Para aplicaciones que serán accedidas de la Internet (o desde cualquier sistema cuyo ancho de banda disponible no puede ser establecido a priori), la demora que introduce el ancho de banda debe ser eliminada del análisis. Es un error realizar pruebas de escalabilidad (y de desempeño en general) a través de la internet (a menos que expresamente se quiera medir este efecto), ya que la distorsión introducida por la transmisión de paquetes TCP/IP no permitirá razonara adecuadamente sobre las demás características del sistema. 

• Se debe tener un adecuado dimensionamiento de los clientes desde los que se generarán las solicitudes. Si se disparan todas las solicitudes de una misma máquina, por ejemplo, la maquina cliente podría degradarse, en vez del servidor, arrojando resultados erróneos en la prueba. No es recomendable realizar estas pruebas sin simuladores automatizados de carga que puedan ser desplegados en una topología distribuida. 

• Los límites de escalabilidad deben ser establecidos sólo en función de escenarios que saturen a los servidores. Es un error pensar que por ejemplo, si el sistema sin estar saturado arroja un consumo de 4 GB de RAM cuando hay solo 10 usuarios concurrentes, se puede concluir que el sistema requiere de 102,4 MB/usuario. Esta conclusión es errónea y engañadora, pues no considera que: 
• El consumo podría deberse a reservas o gestión de la memoria que hace el middleware o la infraestructura anticipándose a una potencial demanda. 
• Que tanto el middleware como la infraestructura puede tener mecanismos avanzados de compartición de recursos, y que gracias a esto podrían soportar mucho más que lo que sugeriría una proyección lineal. 
• Siguiendo con el ejemplo, si este mismo sistema se saturarse a los 50 usuarios, el consumo real arrojado sería 20,48 MB/usuario, 5 veces más de lo que arrojó la medición parcial en estado de no saturación. 

• Los escenarios deben ser ejecutados simulando el comportamiento real de los usuarios. Las herramientas de automatización permiten que los escenarios grabados sean ejecutados a una velocidad mayor, y en muchas ocasiones los escenarios se corren casi sin pausas entre las acciones, para simular una alta demanda. Esta simulación de alta demanda es en realidad un error, pues no existen en la realidad usuarios (humanos) que no hagan pausas mientras ejecutan las distintas acciones del escenario (lo que técnicamente se le llama think time). Omitir artificialmente el think time, no solo fuerza al sistema a trabajar más de la cuenta en situaciones irreales, sino que dificulta razonar adecuadamente en torno a los usuarios que realmente fueron atendidos. 100 usuarios concurrentes no significa 100 usuarios demandando al sistema al mismo tiempo, sino que 100 usuarios trabajando de manera tal que envían solicitudes al sistema que muy probablemente llegarán en distintos instantes de tiempo.

Fuente:

• Guías de planificación de capacidad para productos de Middleware Oracle