Todos los que programamos, ya sea aplicaciones web o simplemente aplicaciones, independientemente de la plataforma, solemos hacerlo con mucho cariño, sobre todo si es un proyecto que nos interesa, ya sea por los resultados o por el simple hecho de tener un reto y aprender de él.

Generalizando un poco, se podría decir que los programadores engullimos grandes cantidades de información, tutoriales, artículos… para implementar todas las mejoras posibles (Optimizaciones, protecciones de seguridad, caché… ), sobre todo si la vamos a mostrar al público en general (como es el caso de una aplicación web).

Llega el esperado momento de terminar, hasta ahora todo está correcto, tenemos nuestra aplicación funcionando en nuestra máquina y parece que casi todos los bugs están solucionados, normalmente (si no estamos en un entorno profesional) es el mismo programador y algún colega de confianza, el que prueba la aplicación en su propio PC.

¿Dónde surge el problema?

Como en el entorno de desarrollo probamos nuestra aplicación con pocos usuarios no podemos comprobar cuanta CPU y memoria va requerir nuestra aplicación en un entorno real y en situaciones límite.

Un ejemplo es, que algún contenido de nuestra web aparezca en un blog popular o que sea portada en sitios como menéame, donde podamos recibir cientos de visitas en escasos minutos.

Hay algunas webs programadas por los “newbies” que por ejemplo sacan un listado con todos los registros de la base de datos, esto no puede parecer un problema cuando estás programando y tienes un par de registros de prueba, pero una vez que nuestra base de datos crezca… pues imagina las consecuencias de varios usuarios a la vez intentando recuperar 12.000 registros de la base de datos… ¿Resultado? Sobrecarga de nuestro servidor y probablemente muchos usuarios no podrán acceder al contenido.

Por ello es recomendable que monitorizemos nuestra aplicación y sepamos qué partes consumen más CPU, y cuales se podrían optimizar para conseguir un mayor rendimiento.

Un ejemplo de optimización sería una tienda de coches online (es lo primero que se me ha ocurrido), si un cliente quiere comprar coches de la marca “Seat”, en vez de sacar el listado con todos las demás marcas, podemos filtrar ese resultado ajustándonos a lo que el cliente requiere. Con ello reduciremos carga de CPU al servidor, haremos que nuestra aplicación vaya mucho más ligera y todo ello influirá en el tiempo que los usuarios tienen que esperar .

¿Cómo puedo medir el rendimiento?

Con todas las distribuciones de Apache se incluye la herramienta Apache Bench. La utilidad de este programa es enviar varias peticiones simultáneas a nuestro servidor y así poder comprobar el tiempo que tarda en cargar y procesar cada página, el número de peticiones que se han podido servir, la carga del servidor y otros datos interesantes.

Apache Bench es, por decirlo de alguna manera, “independiente” del resto, es decir, no tiene porqué ser Apache, puedes usarlo con cualquier servidor, como LigHTTPD o con cualquiera que soporte el protocolo HTTP.

Normalmente se recomienda usar en un entorno local para obtener resultados más fiables y seguramente no querrás probarlo en tu servidor de producción .

¿Cómo se usa Apache Bench?

Apache Bench (ab) normalmente viene incluida con nuestro Apache, si estás en un entorno linux probablemente ya tengas Apache instalado, en cambio en Windows no viene incluido, por lo que si aún no lo tienes instalado te recomiendo XAMPP, puedes descargarlo en la página del proyecto.

Si abrimos el programa (ab.exe en Windows) sin ningún comando nos aparecerá la ayuda del programa:

C:\xampp\apache\bin\>ab
ab: wrong number of arguments
Usage: ab [options] [http://]hostname[:port]/path
Options are:
    -n requests     Number of requests to perform
    -c concurrency  Number of multiple requests to make
    -t timelimit    Seconds to max. wait for responses
    -p postfile     File containing data to POST
    -T content-type Content-type header for POSTing
    -v verbosity    How much troubleshooting info to print
    -w              Print out results in HTML tables
    -i              Use HEAD instead of GET
    -x attributes   String to insert as table attributes
    -y attributes   String to insert as tr attributes
    -z attributes   String to insert as td or th attributes
    -C attribute    Add cookie, eg. 'Apache=1234. (repeatable)
    -H attribute    Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
                    Inserted after all normal header lines. (repeatable)
    -A attribute    Add Basic WWW Authentication, the attributes
                    are a colon separated username and password.
    -P attribute    Add Basic Proxy Authentication, the attributes
                    are a colon separated username and password.
    -X proxy:port   Proxyserver and port number to use
    -V              Print version number and exit
    -k              Use HTTP KeepAlive feature
    -d              Do not show percentiles served table.
    -S              Do not show confidence estimators and warnings.
    -g filename     Output collected data to gnuplot format file.
    -e filename     Output CSV file with percentages served
    -h              Display usage information (this message)

De momento los comandos que nos interesan son: -n y -c.

El comando -n seguido de un número indica la cantidad de peticiones a realizar. Un número entre 100 y 1000 es un buen valor para comenzar

El comando -c seguido de un número indica las peticiones simultáneas que se realizarán. Este valor puede variar bastante dependiendo de qué esperas de tu aplicación. En nuestro caso pondremos un valor de 30.

Para nuestra prueba usaremos la siguiente dirección: “http://localhost” que es la dirección local por defecto  cuando instalamos Apache, para lanzar ab usaremos lo siguiente:

ab -n 1000 -c 30 http://localhost/

Lo que le estamos pidiendo al programa es que realize 30 peticiones simultáneas por segundo hasta completar las 1000 peticiones. El programa nos muestra lo siguiente:

This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

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
Finished 1000 requests

Server Software:        Apache/2.2.8
Server Hostname:        localhost
Server Port:            80

Document Path:          /
Document Length:        1789 bytes

Concurrency Level:      30
Time taken for tests:   26.828125 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      2020000 bytes
HTML transferred:       1789000 bytes
Requests per second:    37.27 [#/sec] (mean)
Time per request:       804.844 [ms] (mean)
Time per request:       26.828 [ms] (mean, across all concurrent requests)
Transfer rate:          73.50 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   3.1      0      15
Processing:   125  797 170.9    796    1297
Waiting:      125  797 170.8    796    1296
Total:        125  798 170.9    796    1312

Percentage of the requests served within a certain time (ms)
  50%    796
  66%    859
  75%    906
  80%    921
  90%   1015
  95%   1078
  98%   1140
  99%   1187
 100%   1312 (longest request)

Si deseas más información puedes consultar la ayuda oficial.

No hay entradas relacionadas.

Related posts brought to you by Yet Another Related Posts Plugin.