Prueba de carga y estrés con Jmeter

Performance Testing o prueba de rendimiento tiene como objetivo eliminar “cuellos de botella” en la ejecución de una aplicación y poder determinar una medida aceptable para su funcionamiento,

Con esa simple definición podemos conocer profundamente la intención  de realizar este tipo de pruebas a nuestros servicios o aplicaciones y tener una perspectiva de su funcionamiento,

Load Testing o prueba de carga es un proceso progresivo en el cual se va aumentando la carga (usuarios, transacciones, peticiones) en el sistema.

Stress Testing o prueba de estrés en esta se busca forzar a una falla en el sistema excediendo los recursos y verificar su comportamiento ante esta situación.


¿Por qué utilizar este tipo de pruebas?

Por que nos ayuda a encontrar fallas en los servicios y tener una perspectiva de su solidez antes de entrar a producción, las pruebas de estrés aumentan la posibilidad de encontrar errores de concurrencia o problemas de memoria (Buffer Overflow)

¿Cual es la diferencia entre los test load y stress?

Normalmente se ven como sinónimos, sin embargo el concepto de pruebas de estrés abarca mas allá que un test de carga, y nos ayuda a determinar el comportamiento de un sistema bajo un nivel de exigencia (Stress) mayor al que es capaz de manejar, de ahí el origen de su nombre.

En estos Test el sistema se satura y los escenarios más comunes suelen ser:

• El sistema apila y desecha peticiones
• El sistema responde con una latencia a las peticiones.
• El sistema colapsa y queda fuera de línea. (DOS)

En términos simples:
Load Testing = Gran cantidad de usuarios
Stress Testing = Demasiados usuarios, demasiados datos, demasiadas peticiones, poca memoria, poco espacio

Los ataques DOS o DDOS están basados en este principio inundan de peticiones el objetivo llevando a un nivel de estrés y si no se encuentra bien protegido el objetivo colapsa.

Test

Normalmente este tipo de pruebas suelen ser usados en servidores web's llámese Apache, Nginx, lighthttpd, Cherokee o incluso IIS. pero tambien puede usar el mismo principio para pruebas de software (Desktop) o cualquier sistema de información.

Todos estos servidores web en su configuración por defecto trabajan excelente pero los sitios web albergados pueden convertirse en una fuente de carga estresante para el servidor y forzando a colapsar los servicios.

Existen diversas formas tanto manuales, y herramientas automatizadas para realizar este tipo de pruebas. algunos automatizados son Jmeter, siege, ab (ApacheBench),

Nuestro ambiente de simulación es el siguiente:

• Servidor CentOS 6.3
• Apache 2.2.15 (Configuración por defecto) lo invito a ver el hardening de esta app
• PHP 5.3.3

Simulare un esfuerzo con la herramienta Jmeter de Apache con el se pueden realizar pruebas de carga y stress sobre servidores, esta herramienta requiere una version java >= 1.6:

• Web - HTTP, HTTPS
• SOAP
• BD via JDBC
• LDAP
• JMS
• Mail - SMTP(S), POP3(S) y IMAP(S)

JMeter puede hacer peticiones distribuidas puede encontrar mas info aqui
Una vez tenga instalado el Jmeter ejecutamos el script Jmeter ubicado /bin dentro de la carpeta de Jmeter  esto si quiere usar el modo GUI.

Al ejecutarlo nos encontraremos con la GUI  en el cual nos solicita crear un plan de Pruebas :

Un plan de prueba se compone de una secuencia de componentes que determinaran cómo se simulará la prueba de carga. Ahora podemos añadir elementos a este plan de pruebas. jMeter permite muchos tipos diferentes de peticiones a practicar como mencione anteriormente, nosotros nos limitaremos al HTTP


1. Agregamos un Thread Group

• Clic derecho en Test Plan >Add>Threads (Users) >Thread Group 

Thread Group tiene tres propiedades particularmente importantes que influyen en la prueba.

• Number of Threads (users): Numero de usuarios a simular
• Ramp-Up Period (in seconds): Tiempo que Jmeter distribuira los Threads
• Loop Count: El numero de veces que se ejecutara la prueba.

2. Agregamos un HTTP Request Defaults

• Clic derecho en Test Plan >Add>Config Element >HTTP Request Default 

Este elemento es utilizado para establecer los valores predeterminados para las peticiones HTTP en nuestro plan de pruebas.

En este elementos llenamos los datos del servidor solicitados para la prueba. 

3. Agregamos el elemento HTTP Request Sampler

• Clic derecho en Thread Group >Add>Sampler >HTTP Request

Debemos tener en cuenta que no es necesario especificar los datos del servidor en este elemento debido a que ya se ha especificado en el elemento de HTTP Request Defaults.

Nota: Si desea agregar más solicitudes HTTP como parte de la prueba, se debe repetir este paso. Cada Thread llevará a cabo todas las peticiones en este plan de pruebas.

3. Agregamos el elemento View Results in Table Listener

• Clic derecho en Thread Group >Add>Listener>View Results in Table

Con este elemento podemos visualizar la interacción de Jmeter hacia nuestro aplicativo ejerciendo la prueba una vez ejecutada la prueba.

la tabla refleja la iteracion del HTTP Request.

de esta manera podemos realizar simulaciones de estres y podemos ir forzando y ejerciendo mas iteraciones a medida que veamos el comportamiento del sistema de información.

Proceso de optimización

Como cualquier tema en auditoria despues de realizar estas pruebas, el sysadmin debe pasar a un proceso de optimizacion para solucionar los fallos encontrados en el sistema. el proceso difiere de acuerdo al sistema de informacion por ejemplo si el sistema se trata de un servidor de base de datos se debe ejercer una optimizacion a su configuración por ejemplo, caché de consultas, contemplar mayor recursos, analizar velocidad de escritura en disco, caché de objetos para evitar lecturas desde base de datos (memcached, APC, etc). Utilización de sistemas de caché estático (nginx como proxy inverso, Varnish, etc).
Si se trata de un servidor web: realizar un hardening al servidor web, denegar las multiples peticiones, Mantener una bitacora firewall (Para muchos algo de poca relevancia - pero es de lo mas importante para un sysadmin), ejercer el uso IPS e IDS,