martes, 27 de septiembre de 2011

Ancho de banda disponible en Cloud Testing

1 Ancho de banda en Cloud Testing

Durante las pruebas de rendimiento de un sistema es importante asegurarnos que no existe ningún elemento ajeno a la aplicación que pueda actuar como limitador de la inyección de carga. La capacidad de los inyectores de carga y el ancho de banda disponible deben ser elementos que debemos tener controlados durante un proceso de pruebas de rendimiento. En esta entrada nos centraremos en los problemas asociados al ancho de banda y a la lantencia. 

En un entorno clásico de pruebas (hosting), los inyectores de carga se sitúan "lo más cercanos" posible a los servidores de la aplicación bajo pruebas. Esto permite disponer de un ancho de banda próximo al de la red corporativa y que las peticiones que realicen "pasen" por un número mínimo de elementos de red (routers, hubs, switches, etc...)

En la actualidad, el crecimiento de entornos Cloud, y la necesidad de utilizar técnicas Cloud Testing para realizar las pruebas de rendimiento impide que tengamos controlado el ancho de banda del que disponemos. Los inyectores de carga en un entorno Cloud Testing se encuentran distribuidos en situaciones geográficas alejadas de los servidores, de forma que la red puede influir negativamente en nuestras pruebas.

2 La red como cuello de botella

Después de realizar una prueba de rendimiento podemos encontrarnos un punto de saturación que no corresponda con la saturación de otros elementos en la plataforma de la aplicación: CPU de los servidores, memoria, etc...

Cuando se produce esto, es necesario que nos tomemos un tiempo en comprobar el ancho de banda del cual disponemos para asegurarnos que la red no es un cuello de botella.

El Test de ancho de banda es aplicable a entornos de pruebas clásicos donde los inyectores se encuentran dentro de la red corporativa, pero es extremadamente necesaria realizarla cuando las pruebas de rendimiento se realizan sobre entornos de Cloud Testing, ya que en ese caso la red no es un elemento que podamos controlar, y es necesario seleccionar aquellos inyectores de carga en una situación geográfica adecuada.


3 Test de ancho de banda 

Los problemas asociados a la red en las pruebas de carga no son fáciles de desenmascarar. De hecho, demostrar que la red es un cuello de botella para nuestras pruebas de carga es una tarea complicada. En cambio, demostrar la red NO es el problema, es una tarea relativamente sencilla.

El Test consiste básicamente en realizar una prueba de carga contra una URL de nuestra aplicación controlando el tamaño de la misma y las carácterísticas. Nuestros scripts y nuestra herramienta de pruebas la debemos configurar adecuadamente:
  • La URL debe hacer referencia a un elemento estático de nuestra aplicación. No es conveniente seleccionar peticiones que implique a la capa lógica de la aplicación.
  • El tamaño del elemento estático no debe ser excesivamente pequeño. Un tamaño entre 50 y 500 Kbytes es suficiente. En otro caso nuestra en prueba podría verse afectada por la propia latencia de red.
  • Debemos seleccionar peticiones que implique elementos "non-compressible" y que en las cabeceras de la  petición aparezca explicitamente la opción "non-compressed". De esa forma garantizamos que los servidores no comprimirán el elemento que estamos pidiendo en el test.
  • Debemos usar peticiones persistentes. Forzar a que se abra una nueva conexión en cada petición añade una mayor latencia.
  • No utilizar peticiones SSL. La encriptación es un procedimiento costoso y añade un mayor tiempo de respuesta.
  • No utilizar la simulación de caché de los navegadores durante la prueba. En caso contrario la petición no recibirá el tamaño completo del elemento, tan solo la confirmación de que el elemento no ha cambiado y que se encuentra cacheado (HTTP code 304).
  • Realizar la prueba seleccionando varios inyectores de carga. Idealmente intentaríamos realizar el test de ancho de banda con los mimos inyectores que en la prueba de carga de nuestra prueba.
  • Utilizar un número de Usuarios Virtuales relativamente elevado (superior a 10).

Una buena solución es seleccionar para la prueba un elemento ya comprimido y de tamaño medio. Por ejemplo elementos con extensión *.gif, *.mp3, etc... A modo de ejemplo se muetra una petición de URL en la sintáxis de LoadRunner:
    web_url("icoazul.gif",
        "URL=http://servidor:puerto/base/img/icoazul.gif",
        "Resource=1",
        "RecContentType=image/gif",
        "Referer=http://servidor:puerto/base/frameabajo",
        LAST);
Con estas condiciones realizaremos una prueba de carga y observaremos los resultados del througput (Bytes/s) que obtenemos durante ella. 

Si el througputh alcanzado en el test de ancho de banda es superior al alcanzado en la prueba de rendimiento contra la aplicación, debemos descartar que la red no puede ser un cuello de botella, y que por lo tanto debe existir otro elemento que limite el rendimiento de nuestra aplicación.



En el caso de el througputh sea similar en el test de ancho de banda y en la prueba de rendimiento, cabe la posibilidad de que hayamos saturado la capacidad de inyección de los inyectores. En ese caso debemos repetir el test pero seleccionando un número mayor de inyectores. Si doblamos el número de inyectores, el throughput debe incrementarse en la misma proporción. Si por el contrario el throughput se mantiene en los mismos valores, debemos valorar la posibilidad de que la red sea un cuello de botella en nuestra capacidad de inyección.

1 comentario:

  1. Interesante informacion, donde trabajo usamos software de terceros para crear guiones de prueba y hace realizar pruebas de carga en nuestras aplicaciones web, asi como en las paginas que creamos para empresas importantes.

    ResponderEliminar