Apache Benchmark + GNUPlot: Medir y graficar el rendimiento de tu servidor web

Da igual si se usa Nginx, Apache, Lighttpd u otro, cualquier administrador de red que tenga un servidor web deseará en algún punto saber qué tan rápido responde el servidor web a un número determinado de consultas.

Apache Benchmark + GNUPlot

En esta ocasión usaremos una herramienta llamada Apache Benchmark, que aunque tiene ‘apache’ en su nombre, NO sirve solo para medir el rendimiento de Apache, sino también se puede usar para Nginx y otros. En realidad, yo lo usaré para medir el rendimiento de Nginx.

Usaremos además GNUPlot, que nos servirá para hacer gráficas como estas con unas pocas líneas:

Instalando Apache Benchmark y GNUPlot

Apache Benchmark es una herramienta que podremos usar después de instalar el paquete de Apache, GNUPlot estará disponible luego de instalar el paquete de igual nombre. Por lo que entonces…

En distros como Debian, Ubuntu o similares:

sudo apt-get install apache2 gnuplot

En distros como ArchLinux o derivadas:

sudo pacman -S apache gnuplot

Solo necesitamos instalar el paquete de Apache, no necesitamos iniciarlo ni configurar algo más, con instalarlo bastará.

Usando Apache Benchmark

Lo que haremos será enviar un número determinado de peticiones (100) en grupos de varias (de 20 en 20) a un sitio determinado. El resultado lo guardaremos en un archivo .csv (resultado.csv) para luego procesarlo con GNUPloit, la línea sería:

ab -g resultados.csv -n 100 -c 20 http://nuestro-sitio-web.com/

Es muy importante poner el / final en la URL del sitio a medir.

Este es el output o log que me muestra cuando hago la prueba a un sitio en mi red:

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

Benchmarking gutl.jovenclub.cu (be patient).....done

Server Software:        nginx
Server Hostname:        gutl.jovenclub.cu
Server Port:            80

Document Path:          /
Document Length:        206 bytes

Concurrency Level:      20
Time taken for tests:   0.101 seconds
Complete requests:      100
Failed requests:        27
(Connect: 0, Receive: 0, Length: 27, Exceptions: 0)
Non-2xx responses:      73
Total transferred:      1310933 bytes
HTML transferred:       1288952 bytes
Requests per second:    993.24 [#/sec] (mean)
Time per request:       20.136 [ms] (mean)
Time per request:       1.007 [ms] (mean, across all concurrent requests)
Transfer rate:          12715.49 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    1   0.2      1       1
Processing:     1   17  24.8      4      86
Waiting:        1   15  21.5      4      76
Total:          1   18  24.8      5      87

Percentage of the requests served within a certain time (ms)
50%      5
66%      6
75%     22
80%     41
90%     62
95%     80
98%     87
99%     87
100%     87 (longest request)

Les he marcado en rojo lo que considero yo, es lo más importante, que viene siendo más o menos:

  1. Datos del servidor que estamos probando, así como la URL en cuestión.
  2. Cantidad de peticiones por segundo.
  3. Cuantos milisegundos demoró el servidor en atender la petición que más demoró, o sea, la que más tardó en ser atendida.

Con esta información pueden tener una idea de cuánto demorará el servidor en atender esa cantidad de solicitudes, pueden luego agregar un mejor sistema de caché, desactivar módulos que no usen, etc etc, volver a ejecutar la prueba y ver si el rendimiento mejoró o no.

Les recomiendo correr la prueba 2 o 3 veces, para que creen algo así como un margen, pues rara vez los resultados de dos pruebas seguidas son idénticos.

Otras opciones o parámetros útiles de Apache Benchmark:

-k -H ‘Accept-Encoding: gzip,deflate’ : Con esto ab aceptará el caché y compresión que el servidor tenga configurado, por lo que los tiempos serán inferiores.

-f urls.txt : Entonces en vez de solo probar el index del sitio, irá efectuando pruebas en las URLs que especifiquemos en ese archivo.

En fin… échenle un ojo a man ab para que vean.

Mostrar en un gráfico el resultado:

Para poner en una imagen este output, o sea, en un medio más visual y que muchas veces, es todo lo que los directivos logran entender … para ello usaremos como ya dije antes, GNUPlot

En la misma carpeta donde tenemos el archivo resultados.csv (que recuerdan, acabamos de generar con el comando anterior) vamos a crear un archivo llamado gnuplot.p:

nano plot.p

En él pondremos lo siguiente:

set terminal png size 600
set output "resultados.png"
set title "100 peticiones, 20 peticiones concurrentes"
set size ratio 0.6
set grid y
set xlabel "peticiones"
set ylabel "tiempo de respuesta (ms)"
plot "resultados.csv" using 9 smooth sbezier with lines title "gutl.jovenclub.cu"

Les he señalado en rojo lo que deberían revisar siempre. O sea y de arriba hacia abajo:

  1. Nombre del archivo de imagen que se generará
  2. Cantidad de peticiones totales y concurrentes.
  3. Nombre del archivo que recién acabamos de generar.
  4. Dominio sobre el que trabajamos.

Una vez ponemos eso, guardamos y salimos (Ctrl + O y luego Ctrl + X), ejecutaremos lo siguiente:

gnuplot plot.p

Y listo, eso nos generará el gráfico con el nombre deseado, el mío es:

Fin!

Apache Benchmark tiene un montón más de opciones, son muchas combinaciones también que podemos usar para que nuestra prueba de rendimiento sea aún más completa.

Pero bueno, esto ha sido lo básico 😉

Enjoy!


9 comentarios

  1.   Francisco dijo

    Interesante apache benchmark, lo de gnuplot no lo conocía es posible modificar el estilo de la salida?? digo como para un reporte formal.

    Saludos desde Chile.

    1.    KZKG^Gaara dijo

      Sí, hay un montón de configuraciones en la red para gnuplot, busca por Google a ver si encuentras alguna lo suficientemente seria o profesional para que la uses, pues ya eso es gusto de cada cual 🙂

  2.   Wolf119 dijo

    Ummm lo voy a probar ahora mismo en un server apache virtual que tengo corriendo para ver como va esto, con respecto a GUTL, como que se dispara de una forma muy rapida a partir de las 80 peticiones no?, a ver que 100 ms no son nada, pero me llama la atencion el subidon que da por 10 peteciones mas comparado con 70 a 80 con 80 a 90

    1.    KZKG^Gaara dijo

      Debe ser por la cola o cantidad de hilos máximos a atender de forma simultánea. No obstante, la prueba la hice sin gzip, sin deflate, sin caché ni nada 😉

  3.   Charlie-Brown dijo

    Muy interesante, sobre todo por el uso de GNUPlot. Por lo que veo puede ser usado para generar gráficos a partir de casi cualquier conjunto de datos ¿o no?…

    1.    KZKG^Gaara dijo

      Sí claro, le pasas los datos en un archivo separado por comas o algo así, le indicas cómo procesarlos en el archivo de configuración, y listo

  4.   Adolfo dijo

    Hola, siempre me la paso leyendo este blog pero nunca he comentado ningun articulo, y esta me parece una buena oportunidad.
    Lo que quiero compartirles es que este tipo de grafico puede malinterpretarse, debido a que Apache Bench ordena el resultado usando ttime (total time) en vez del tiempo secuencial. Aunque los datos siguen siendo verdaderos, probablemente el grafico no muestre lo que queremos.
    Aqui les dejo el link donde lo lei.
    http://www.bradlanders.com/2013/04/15/apache-bench-and-gnuplot-youre-probably-doing-it-wrong/

    Saludos.

  5.   Hugo dijo

    Apache Benchmark no es la mejor herramienta para medir el rendimiento de servidores HTTP en equipos con multiples núcleos, además, solo 100 peticiones con 20 conexiones concurrentes es una prueba muy débil, algo más realista serían 1,000 o 10,000 peticiones con 100 conexiones concurrentes (es sabido que Nginx es una de las aplicaciones capaces de servir más de 10,000 peticiones por segundo) y para esto es mejor usar una herramienta como weighttp, que esta concebida para equipos con multiples núcleos y usa epoll que es más rápido, a diferencia de Apache Bench que usa un solo hilo y un mecanismo de gestión de eventos menos eficiente.

    Para aterrizar mi punto, suponiendo que el servidor tenga solo 4 núcleos:

    weighttp -n 10000 -c 100 -t 4 -k “http://nuestro-sitio-web.com/”

  6.   fede dijo

    Hola a todos,
    al trazar el grafico (a partir del CSV) con gnuplot me da el sgte error, ¿me podeis decir como solucionarlo?

    “plot.p”, line 8: warning: Skipping data file with no valid points

    plot “grafica.csv” using 9 smooth sbezier with lines title “AB – localhost/web”
    ^
    “plot.p”, line 8: x range is invalid

    Con gnuplot, ¿tmbien puedo generar paginas HTML?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.