AB, duelo al sol con Apache HTTP Server

Siguiendo con las pruebas de rendimiento de los entornos que tenemos entre manos, y una vez que JMeter ya nos ha dado cierta tranquilidad en cuanto a los contenedores de aplicaciones, ahora toca poner a prueba al servidor HTTP Apache, que estará delante de los primeros (si eso puede ser posible) en la arquitectura de red y por tanto tendrá que soportar todas las peticiones que luego se derivarán a cada contenedor, así como su respuesta.

Para los tests, hemos elegido a “ab”, que como ya se tiene directamente en Ubuntu, parecía la opción más “normal”.

Si bien es muy sencillo de usar, os dejo el enlace a su página oficial, donde podéis consultar el detalle de cada opción.

Nosotros hemos tirado la siguiente prueba:

ab -n 10000 -c 1000 http://vitallogistics.es/

Es decir, hemos tirado un total de 10000 peticiones, con 1000 de ellas concurrentes, con un ssh abierto al servidor por lo que pudiera pasar.

Los resultados que nos da ab son los siguientes:

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking vitallogistics.es (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests

Server Software:        Apache/2.2.3
Server Hostname:        vitallogistics.es
Server Port:            80

Document Path:          /
Document Length:        55 bytes

 

 

Concurrency Level:      1000
Time taken for tests:   73.232 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Non-2xx responses:      10000
Total transferred:      4890000 bytes
HTML transferred:       550000 bytes
Requests per second:    136.55 [#/sec] (mean)
Time per request:       7323.236 [ms] (mean)
Time per request:       7.323 [ms] (mean, across all concurrent requests)
Transfer rate:          65.21 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       24  817 2848.3     51   25652
Processing:    24 1271 3818.2     89   59049
Waiting:       24 1249 3763.0     89   59049
Total:         53 2088 4879.3    185   62111

 

Percentage of the requests served within a certain time (ms)
  50%    185
  66%    420
  75%    931
  80%   3126
  90%   7301
  95%  11156
  98%  14142
  99%  24905
 100%  62111 (longest request)

Es decir, nos da un buen número de datos generales, como el tiempo totales invertidos en la prueba, el tamaño total descargado, número de errores, tiempos medios de respuesta y velocidad media de la respuesta .

Pero lo interesante, creemos, de interpretar, viene al final.

Podemos ver en qué parte de la petición se está consumiendo qué tiempo. Si es en la conexión y procesamiento de la petición, puede que nuestro equipo sea el cuello de botella (desde donde hacemos las peticiones), pero si el tiempo está en la espera, entonces tenemos un potencial de mejora en la configuración del apache.

Finalmente, podemos ver qué porcentaje de peticiones han sido atendidas en un determinado tiempo. Tiene una interpretación muy interesante. En nuestro caso, por ejemplo, el 75% de las peticiones se respondieron en menos de un segundo, un 95% antes de once segundos (ya es mucho, pero en un escenario de 1000 concurrentes significa que a 950 se les responde antes de 11 segundos) y sólo a un 2% se les responde en más de catorce.

Un ejercicio paralelo interesante mientras se hace la prueba es tirar un “top” en el servidor de destino para ver los hilos del apache multiplicarse para atender las peticiones, y ver si el consumo de memoria se acerca al barranco del swapping, donde tendremos un descenso acusado del rendimiento (añade RAM para evitarlo), o si estamos llevando al límite a la CPU (añade otra…).

En fin, que una prueba sencilla, de un par de minutos, puede darnos suficiente información como para dejar tranquilos a los clientes o realizar acciones preventivas antes de llegar a tener caídas de rendimiento significativas sin control.

¿Hacéis pruebas de este tipo habitualmente sobre vuestros entornos de producción o son los departamentos de sistemas de vuestros clientes quienes se encargan? ¿Tenéis algún software de testing similar? ¿Es el rendimiento final algo que se tiene en cuenta en vuestros desarrollos o suele quedar para el mantenimiento / fase 2?