Tiempo de lectura: 3 minutos

Uno de los factores más críticos cuando trabajamos con sistemas distribuidos es el rendimiento, el cual puede lastrarse por motivos que a priori no identificamos como pudiera ser una base de datos con bloqueos o una instancia de una máquina que no cubre los requerimientos de memoria que necesitamos (entre otras).

Para ello hay una potente y sencilla herramienta que es ApacheBench, la cual llevo usando varios años, y os voy a detallar muy por encima lo básico para poder usarla junto a gnuplot por si queremos tener algún tipo de información visual de lo que pasa si lanzamos una batería de peticiones contra nuestra aplicación o servicio.

Vamos a la chicha con un ejemplo, un script al que he llamado run.sh

#!/bin/bash
# -g save the test result in a given file
# -p for POST it or -u PUT to select the file that contains the json or xml you want to send
# -T mime type, usually application/json or application/xml
# -H adds an Auth header (could be Basic or Token)
# -T sets the Content-Type
# -c number of concurrent clients
# -n number of total requests to run in the test

ab -g output.tsv -u request.json -T application/json -H 'Authorization: Basic ...' -c 100 -n 2000 http://myservice

 

De esta manera nos lanzaría baterías de peticiones enviando un método http PUT de request.json de 100 en 100 hasta llegar a las 2000, y guardaría el resultado en output.tsv.

Ahora vamos a interpretar el resultado. Nos creamos en la misma carpeta del script arriba descrito el fichero plotconfig.p y dentro podemos poner una configuración de este estilo para generar la imagen de salida:

# output as png image
set terminal png size 1024

# save file to a file
set output "result.png"

# graph title
set title "Peticiones frente a tiempo de respuesta"

# nicer aspect ratio for image size
set size ratio 0.6

# y-axis grid
set grid y

# x-axis label
set xlabel "Peticiones"

# y-axis label
set ylabel "Tiempo de respuesta (ms)"

plot "output.tsv" using 9 smooth sbezier with lines title "App Test"

Ahora para ejecutarlo todo automáticamente al correr el script añadimos esta línea al final, quedando así:

ab -g output.tsv -u request.json -T application/json -H 'Authorization: Basic ...' -c 100 -n 2000 http://myservice

gnuplot plotconfig.p

Deberíamos tener algo así antes y después de ejecutar run.sh :

 

 

 

 

 

 

Finalmente tenemos una gráfica que hemos construído con gnuplot en result.png.

Además, en consola tenemos la salida de ApacheBench:

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        
Server Hostname:        localhost
Server Port:            8080

Document Path:          /api/
Document Length:        185 bytes

Concurrency Level:      100
Time taken for tests:   7.209 seconds
Complete requests:      1000
Failed requests:        0
Non-2xx responses:      1000
Total transferred:      586000 bytes
Total body sent:        1210000
HTML transferred:       185000 bytes
Requests per second:    138.72 [#/sec] (mean)
Time per request:       720.886 [ms] (mean)
Time per request:       7.209 [ms] (mean, across all concurrent requests)
Transfer rate:          79.38 [Kbytes/sec] received
                        163.92 kb/s sent
                        243.30 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   2.9      0      17
Processing:   526  696 171.9    661    1339
Waiting:      526  694 171.4    658    1339
Total:        526  697 174.0    661    1348

Percentage of the requests served within a certain time (ms)
  50%    661
  66%    705
  75%    730
  80%    753
  90%    868
  95%   1170
  98%   1219
  99%   1310
 100%   1348 (longest request)

Con este sencillo ejemplo hemos podido comprobar cómo podemos medir el rendimiento de un servicio (nuestro o de cualquiera, obviamente).

De esta manera podéis construir una batería de pruebas contra una API, por ejemplo, y medir el rendimiento de la misma, ver si hay cuellos de botella o qué problemas de concurrencia pueden darse.

Si quieres más detalles o necesitas ayuda, puedes escribir un comentario o contactar con nosotros en nuestra web http://gloin.es/ o dejando tu comentario debajo.

Ricardo Flores

Software arquebusier doing cool things in @GloinSL. Linux lover ∞ retro garbage necromancer

Deja un comentario