ÍNDICE
Introducción
1. Definiciones
1.1 Tiempo de respuesta
1.2 Carga
1.3 Escalabilidad
1.4 Herramientas de automatización de pruebas
1.5 Herramientas de prueba de carga
1.6 Perfilador
2. Un proceso para la prueba de rendimiento.
2.1 Pruebas funcionales
2.2 Pruebas de carga y escalabilidad
2.3 Interpretación de los resultados
2.4 Optimización
3. Pruebas de carga y escalabilidad
4. Interpretando los resultados
5. Optimización
6. Empirix’s-e Test Suite
7. Mercury LoadRunner
8. TPC Benchmark W (TPC-W)
9. PushToTest:
10. Probando y optimizando THESERVERSIDE.COM
Conclusiones
Bibliografía

INTRODUCCIÓN
Con la introducción de nuevas aplicaciones y plataformas de desarrollo, las infraestructuras de la Web están llegando a ser cada vez más complejas. Las herramientas de pruebas de la Web le ayudarán a los programadores a determinar el funcionamiento del servidor bajo cargas anticipadas y observar cuál será su desempeño ante pruebas de rendimiento, pero encontrar la herramienta justa para satisfacer los requisitos de prueba de una empresa puede ser un desafio.

El propósito de este trabajo es explicar que se debe hacer para llevar a cabo pruebas de escalabilidad, pruebas de rendimiento y optimicación en un entorno J2EE ( Java 2 enterprise edition) y cómo seleccionar el software adecuado para realizar estas pruebas.

1. DEFINICIONES
1.1 Tiempo de respuesta (Response Time) – El tiempo que pasa entre la petición inicial y la descarga completa de la respuesta (es decir, el desplegado por entero de la página web).

1.2 Carga (Load) – Una medida del uso del sistema. Se dice que un servidor tiene “carga elevada” cuando la aplicación que soporta experimenta un fuerte tráfico.

1.3 Escalabilidad (Scalability) – Una aplicación escalable tiene un tiempo de respuesta que aumenta linealmente cuando aumenta la carga. Dicha aplicación es capaz de procesar cada vez más volumen si se añaden recursos adicionales de hardware de forma lineal (es decir, no exponencial).

1.4 Herramientas de automatización de pruebas (Automation testing tools) – Herramientas (Slik de Segue Software, WebLoad, etc.) que se usan para simular un usuario haciendo peticiones de páginas o ejecutando flujo de trabajo preprogramado en un sitio web.

1.5 Herramientas de prueba de carga (Load Testing tools) - La mayoria de las herramientas de automatización de pruebas (por ejemplo, WebLoad) pueden usarse como software de pruebas de carga. Estas herramientas simulan cualquier cantidad de usuarios usando un sitio y proveen datos importantes como, por ejemplo, tiempos medios de respuesta.

1.6 Perfilador (Profiler) – Un perfilador es un programa que examina una aplicación mientras ésta se ejecuta. Provee útil información de ejecución como el tiempo invertido en determinados bloques de código, el grado de utilización de la memoria y del head, el número de instancias de cada clase que hay en la memoria, etc.

2. UN PROCESO PARA LA PRUEBA DE RENDIMIENTO.
2.1 Pruebas funcionales
La mayoria de la aplicaciones comienzan el proceso de pruebas completando, antes que nada, las pruebas funcionales. Es decir, asugurándose que funcionan correctamente todos los casos de usos y los flujos de trabajo de la aplicación.

2.2 Pruebas de carga y escalabilidad
El proceso de probar la carga y la escalabilidad tiene dos aspectos:
a. probar el tiempo de respuesta cuando se aumenta el tamaño de la base de datos.
b. probar el tiempo de respuesta cuando se aumenta el número de usuarios concurentes.

2.3 Interpretación de los resultados
Después de medir el tiempo de respuesta con diferentes cargas y tamaños de la base de datos, se pueden hacer interpretaciones basándose en el tiempo medio de respuesta obtenido en las pruebas y el uso de recursos del servidor durante las mismas.

2.4 Optimización
Después de identificar anomalías en el paso anterior, se interpretan los resultados y se localiza el problema.

3. PRUEBAS DE CARGA Y ESCALABILIDAD
El proposito 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 ejecutar las pruebas de rendimiento, deberá simular el uso del servidor con diferentes cargas. Como regla general, una simulación de carga baja (es de uno a cinco usuarios concurrentes), carga media (10 a 50 usuarios concurrentes), carga alta (100 usuarios concurrentes) y carga extrema (100 o más usuarios concurrentes). Nótese que estos números son arbitrarios y dependen de las necesidades del negocio. Además simular 10 usuarios con software de prueba 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 la web de 30 o 40 personas.

Una vez que 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:

1. 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.

2. 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 los resultados es muy 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:

a. Observe los requerimientos de memoria.
b. 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, probablemente el problema esté en la entrada/salida. Compruebe las conexiones de bases de datos, el número de 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 el perfilador de código.

5. OPTIMIZACIÓN
Se necesita optimizar la base de datos, la arquitectura, la configuración y el hardware. Como se mencionó en el apartado anterior, el motivo más común de que la aplicación no sea escalable es que no se haya afinado la base de datos.
Después de optimizar la base de datos y optimizar la configuración de hardware, el siguiente paso es optimizar el código, esto se hace con un perfilador.

Un perfilador es un programa que analiza la aplicación mientras ésta se ejecuta. Un perfilador provee información a la que no se podría acceder de otra manera, como, por ejemplo:

1. La cantidad de objetos de cada clase que hay en memoria y el comportamiento del recolector de basura (garbage collector)
Esta información puede ayudar a identificar clases que deberian estar en un “pool”.
Tambien puede ayudar a afinar el “heap” de Java.

2. El tiempo que la aplicación se trabaja en determinadas clases
Esta es la función más importante. El perfilador indicará qué clases son los cuellos de botella.

La optimización de la arquitectura es específica para cada proyecto, pero a continuación se incluyen algunos consejos:

1. Asegúrese de que se han minimizado las llamadas a la red, especialmente las llamadas a las bases de datos.
- es mejor tener una base de datos grande que muchas pequeñas.
- confirme que ejbStore no almacena nada para operaciones de lectura.
- use objetos de detalle para obtener el estado de los beans de entidad.

2. Asegúrese de aprovecharse de la cache cuando sea posible
Su servidor de aplicaciones probablemente permite colocar los beans de entidad en la “cache” de memoria. Asegúrese de que se aprovecha de ello, ya que reducirá dramaticamente las llamadas a la base de datos y acelerará el acceso a los datos.

3. Tratar de usar bean de sesión como una fachada de los beans de entidad.
Puede encapsular el flujo de trabajo de un caso de uso completo en una llamada de red a un único método de un bean de sesión(y en una única transacción).

Realizar pruebas de rendimiento y optimizar una aplicación puede ser una tarea muy desafiante. Afortunadamente existen herramientas en el mercado que pueden simplificar el proceso. Usando esas herramientos y siguiendo los pasos sencillos que se han explicado. usted debería ser capaz de seguir la pista a los cuellos de botella de un sistema de forma efectiva.

Alguna de estas herramientas son Empirix’s-e Test Suite, Mercury LoadRunner, TPC Benchmark W(TPCW), Compuware’s, Oiptimize-it entre otros.

6. EMPIRIX’S-E TEST SUITE
Empirix’s-e Test Suite ofrece una herramienta comprensiva para probar aplicaciones web con un ambiente window. La última versión agrega algunas capacidades útiles para realizar pruebas de test a web services. Muchos usuarios plantean que lo que necesitaría empirix es un wizard para hacer el sistema un poco más intuitivo. Con más de 3000 clientes satisfechos y una historia impresionante de innovación, Empirix está redefiniendo las normas para la web y está trabajando en las pruebas de aplicaciones de voz. Empirix’s-e Test Suite cuesta $20,000 para simular 50 usuarios virtuales.

7. MERCURY LOADRUNNER
LoadRunner, de Mercury Interactive, es utilizado para predecir el comportamiento del sistema y su comportamiento bajo condiciones extremas con una pesada carga de usuarios, simulando la actividad de usuarios reales.

Cada uno de estos usuarios utilizan las aplicaciones con transacciones reales, mientras LoadRunner mide los tiempos de respuesta, los retrasos en las redes y el rendimiento, tanto de los servidores como de las aplicaciones, para ayudar a aislar los cuellos de botella y ajustar al máximo el rendimiento dentro de la infraestructura de las aplicaciones. LoadRunner proporciona una monitorización a medida, integrada y en tiempo real, que captura y muestra los datos de rendimiento desde varios niveles del sistema durante la prueba de carga. Estas capacidades permiten a los clientes minimizar sus ciclos de realización de pruebas, optimizar el rendimiento y reducir los costes globales. En fin LoadRunner es complicado, caro y muy bueno.

8. TPC BENCHMARK W (TPC-W)
El TPC Benchmark W (TPC-W), está dedicado a las transacciones web. El volumen de trabajo es ejecutado en un ambiente de comercio internet controlado que simula las actividades de un negocio orientado a las acciones transaccionales del servidor web. Los ejercicios de volúmenes de trabajo asociados a un extenso sistema de componentes de cada ambiente, están caracterizados por:

- Multiples sesiones de navegación “on-line”.
- Generación dinámica de páginas con acceso y actualización de las bases de datos.
- Objetos web consistentes.
- Ejecución simultánea de múltiples tipos de transacciones que abarcan un amplio espectro de complejidades.
- Bases de datos que constan de diferentes tablas, con una amplia variedad de tamaños, atributos y relaciones entre ellas.

Este software también es muy bueno pero caro.

9. PUSHTOTEST
PushToTest presenta TestMaker, una utilidad de código libre para construir agentes encargados de medir la escalabilidad, actuación y funcionalidad de los servicios web. PushToTest personaliza TestMaker a las necesidades específicas del sistema, dirige la escalabilidad y la actuación de la prueba. Este único acercamiento comercial entrega las soluciones baratas.
TestMaker es una aplicación 100% realizada en Java y corre dondequiera que esté instalado Java. Incluso Windows, Linux, Solaris y Macintosh OS X, solamente requiere Java 1.4.1 ó una versión mayor. Además existe el TestMaker 4.0.9 gratis en Internet.

10. PROBANDO Y OPTIMIZANDO THESERVERSIDE.COM
TheServerSide.com experimentó numerosos problemas de escalabilidad antes de su lanzamiento. Usando los pasos mencionados anteriormente, se resolvieron todos los problemas, por lo que TheServerSide.com es uno de los portales basados en Java más rápidos que hay.

El primer paso para probar TheServerSide.com fue llenar la base de datos con datos de prueba. Después de llenarla con una cantidad moderada y con una cantidad extrema (añadiendo 16 000 mensajes y 40 000 usuarios a la base de datos), se encontró un problema serio, el tiempo de respuesta de las páginas de nivel saltó desde los 2 segundos a 12 segundos para un único usuario.

Sin conocer los pasos necesarios se cometieron los errores comunes: doblar la velocidad de la CPU y la memoria de la máquina. Esto sólo redujo el tiempo de respuesta a 8 segundos y, por lo tanto, no era la causa del cuello de botella.

El problema que existente indicaba que algo fallaba en la base de datos. Después de comprobar cómo la base de datos procesaba las consultas, se descubrió que las columnas de clave primaria (y otras) no se indexaban correctamente. Esto significa que la base de datos tenía que hacer búsquedas lineales.

Una vez optimizada la base de datos, se comenzaron a ejecutar pruebas de carga apropiadas, usando WebLoad, una potente herramienta para pruebas de cargas. La copia de evaluación permite probar con 12 usuarios concurrentes (probablemente representativos de 30 ó 40 personas reales). Después de ejecutar las pruebas al máximo (12 usuarios concurrentes), se encontró que el sitio era muy poco escalable. El tiempo de respuesta saltó de los 3 ó 4 segundos de un único usuario a 15 ó 20 segundos por página bajo cargas más pesadas. Obviamente, estos números no eran los suficientemente buenos.

Habiendo optimizado la base de datos y actualizado el hardware, se pasó a examinar la arquitectura. Se hicieron pequeñas modificaciones, pero aún no se podía encontrar la causa del problema. Cuando se empezó a usar un perfilador, todo cambió. Después de ejecutar remotamente Optimize-It (tenía una ventaja en la máquina local, mostraba las estadísticas del servidor ejecutándose en su proveedor de servicios internet), se descubrió la causa del problema, 30 % del tiempo de CPU se perdía en comunicaciones de socket con la base de datos. Optimize-It permitió seguir la pista y ver qué objetos y métodos iniciaban estas llamadas. Así se identificó el problema de diseño que hacía que se consultara un conteo en la base de datos cada vez que querían mostrar un mensaje en TheServerSide.com. Después de arreglar ese problema tonto, el número de llamadas a la base de datos usadas para mostrar una página bajó de 15 a 1, y de repente, el tiempo de respuesta disminuyó a cerca de un segundo. Esto era exactamente lo que se quería.

CONCLUSIONES
A partir del estudio realizado podemos recomendar que una vez se termine la implemntación de los sistemas se realizen las pruebas expuestas anteriormente, siguiendo los pasos necesarios para encontrar posibles errores. De los software existentes y entre los mencionados debeiría utilizarse el TestMaker de PushToTest debido a que se pueden realizar las pruebas fácilmente y se encuantran versiones gratis en internet.

BIBLIOGRAFÍA
1. PushToTest – Free open-source software test automation solutions
http://www.pushtotest.com/ (4/01/08)
2. E-Test Suit Upgrade Tacles Web services
http://www.eweek.com/article2/0,1759,1607658,00.asp (22/10/07)
3. News Article: Empirix e-Test suite 6.0
http://www.empirix.com (5/01/08)
4. Products – Mercury LoadRunner for automated Load Testing
http://www.mercury.com/us/products/performance-center/loadrunner/ (10/01/08)
5. TPC-W
http://www.tpc.org/tpcw/default.asp (10/01/08)

AUTOR
Yoemny González Almaguer

Universidad de la Ciencias Informaticas
Enero 2008