Apache Bench - Guía rápida
Las pruebas de rendimiento han demostrado ser cruciales para el éxito de una empresa. Un sitio de bajo rendimiento no solo enfrenta pérdidas económicas, sino que en ocasiones también puede tener repercusiones legales.
Nadie quiere aguantar un sitio de rendimiento lento y poco confiable en interacciones en línea importantes como compras, exámenes en línea, pago de facturas, etc. Con Internet tan ampliamente disponible, la gama de alternativas es inmensa. Es más fácil perder clientes que ganarlos y el rendimiento es un factor de cambio clave.
Necesidad de una herramienta de prueba de carga
Si podemos entender cuál es la necesidad de una herramienta de prueba de carga, nos dará la razón y la motivación para usarla. Algunos sitios comerciales famosos han sufrido serios tiempos de inactividad cuando reciben una gran cantidad de visitantes. Los sitios web de comercio electrónico invierten mucho en campañas publicitarias, pero no en pruebas de carga. Por lo tanto, no logran garantizar un rendimiento óptimo del sistema cuando ese marketing genera tráfico.
Otro ejemplo familiar de ignorar las pruebas de carga es el de "error al establecer la conexión" en los sitios web de WordPress. Por lo tanto, es una buena idea probar la carga de un sitio web o aplicación antes de su implementación en producción. Es bueno establecer rápidamente el mejor escenario para un proyecto antes de ejecutar pruebas más detalladas en el futuro.
¿Qué es Apache Bench?
Apache Bench (ab) es una herramienta de la organización Apache para comparar un servidor web de Protocolo de transferencia de hipertexto (HTTP). Aunque está diseñado para medir el rendimiento del servidor web Apache, también se puede utilizar para probar cualquier otro servidor web que sea igualmente bueno. Con esta herramienta, puede saber rápidamente cuántas solicitudes por segundo su servidor web es capaz de atender.
Características de Apache Bench
Veamos las características y limitaciones importantes de Apache Bench. Las características y limitaciones se enumeran a continuación:
Al ser un software de código abierto, está disponible gratuitamente.
Es un programa informático de línea de comandos simple.
Es una herramienta independiente de la plataforma. Significa que se puede invocar en Linux / Unix o en un servidor Windows igualmente bien.
Puede realizar pruebas de carga y rendimiento solo para servidores web: HTTP o HTTPS.
No es extensible.
Apache Bench usa solo un subproceso del sistema operativo independientemente del nivel de simultaneidad (especificado por el indicador -c). Por lo tanto, al comparar servidores de alta capacidad, una sola instancia de Apache Bench puede ser en sí misma un cuello de botella. Para saturar completamente la URL de destino, es mejor usar instancias adicionales de Apache Bench en paralelo, si su servidor tiene múltiples núcleos de procesador.
Precaución
Debe tener en cuenta que no existe una directiva en Apache Bench para aumentar la concurrencia en intervalos particulares mientras se ejecutan las pruebas. Por lo tanto, ejecutar pruebas de carga usando ab es equivalente a un ataque de denegación de servicio (DOS). Se recomienda que informe y obtenga el permiso previo de su proveedor de servicios VPS si va a realizar pruebas de carga pesada durante un largo período de tiempo. Le asignarán un intervalo de tiempo apropiado o cambiarán su nodo para la tarea de prueba de carga.
En segundo lugar, si está probando el sitio web de una tercera persona de forma continua y durante mucho tiempo solo para aprender Apache Bench desde su VPS (que se convierte en el nodo de prueba), existe una posibilidad remota de que el sitio web de la tercera persona pueda bloquear su IP pública de VPS permanentemente. En ese caso, no podrá conectarse a ese sitio web con la misma IP. Pero si realmente desea conectarse al sitio web en el futuro, la única solución será hablar con el administrador del sistema del sitio web de destino o crear una nueva instancia del servidor con una IP diferente con la ayuda de su proveedor de servicios VPS.
Habiéndolo advertido, permítame asegurarle que todas las pruebas en este tutorial son lo suficientemente seguras y están fuera de lo que los administradores de sistemas generalmente llaman prácticas de "abuso del sistema".
En este capítulo, lo guiaremos sobre cómo configurar su entorno para Apache Bench en su VPS.
Requisitos del sistema
Memory - 128 MB
Disk Space - Sin requisito mínimo
Operating System - Sin requisito mínimo
Instalación de Apache Bench
Apache Bench es una aplicación independiente y no depende de la instalación del servidor web Apache. El siguiente es un proceso de dos pasos para instalar Apache Bench.
Step 1 - Actualizar la base de datos del paquete.
# apt-get updateTenga en cuenta que el símbolo # antes de un comando de terminal significa que el usuario root está emitiendo ese comando.
Step 2 - Instale el paquete de utils apache2 para obtener acceso a Apache Bench.
# apt-get install apache2-utilsApache Bench ya está instalado. Si desea probar una aplicación web alojada en el mismo VPS, basta con instalar solo el servidor web Apache:
# apt-get install apache2Al ser una utilidad de Apache, Apache Bench se instala automáticamente en la instalación del servidor web Apache.
Verificación de la instalación de Apache Bench
Veamos ahora cómo verificar la instalación de Apache Bench. El siguiente código ayudará a verificar la instalación:
# ab -VOutput
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/Cuando vea la salida del terminal anterior, significa que ha instalado Apache Bench con éxito.
Creación de un usuario de Sudo privilegiado
Desde el punto de vista de la seguridad, se considera una buena práctica para el administrador del sistema crear un usuario sudo en lugar de trabajar como root. Crearemos un usuario de prueba, llamado prueba, con el propósito:
# useradd -m -d /home/test -g sudo testEstablezcamos la contraseña para el nuevo usuario:
# passwd testEl sistema solicitará una nueva contraseña para la prueba de usuario. Puede ingresar una contraseña simple ya que solo estamos probando y no implementando en el servidor de producción. Por lo general, el comando sudo le pedirá que proporcione la contraseña de usuario de sudo; Se recomienda no utilizar contraseñas complicadas ya que el proceso se vuelve engorroso.
Output
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfullyPrueba del sitio web Apache.org
En esta sección, probaremos el sitio web Apache.org. Primero cambiemos a la prueba de usuario de sudo:
# su testPara empezar, probaremos el sitio web de la organización Apache, https://www.apache.org/. Primero ejecutaremos el comando y luego entenderemos el resultado:
$ ab -n 100 -c 10 https://www.apache.org/aquí -nes el número de solicitudes a realizar para la sesión de evaluación comparativa. El valor predeterminado es realizar una única solicitud que generalmente conduce a resultados de evaluación comparativa no representativos.
Y -ces la concurrencia e indica el número de solicitudes múltiples que se deben realizar a la vez. El valor predeterminado es una solicitud a la vez.
Entonces, en esta prueba, Apache Bench realizará 100 solicitudes con concurrencia 10 al servidor de la organización Apache.
Output
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.apache.org (be patient).....done
Server Software: Apache/2.4.7
Server Hostname: www.apache.org
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256
Document Path: /
Document Length: 58769 bytes
Concurrency Level: 10
Time taken for tests: 1.004 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 5911100 bytes
HTML transferred: 5876900 bytes
Requests per second: 99.56 [#/sec] (mean)
Time per request: 100.444 [ms] (mean)
Time per request: 10.044 [ms] (mean, across all concurrent requests)
Transfer rate: 5747.06 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 39 46 30.9 41 263
Processing: 37 40 21.7 38 255
Waiting: 12 15 21.7 13 230
Total: 77 86 37.5 79 301
Percentage of the requests served within a certain time (ms)
50% 79
66% 79
75% 80
80% 80
90% 82
95% 84
98% 296
99% 301
100% 301 (longest request)Después de ejecutar nuestra primera prueba, será fácil reconocer el patrón de uso de este comando, que es el siguiente:
# ab [options .....] URLdónde,
ab - Comando Apache Bench
options - banderas para una tarea particular que queremos realizar
URL - URL de ruta que queremos probar
Comprensión de los valores de salida
Necesitamos comprender las diferentes métricas para comprender los diversos valores de salida devueltos por ab. Aquí va la lista:
Server Software - Es el nombre del servidor web devuelto en el encabezado HTTP de la primera devolución exitosa.
Server Hostname - Es la dirección DNS o IP proporcionada en la línea de comando.
Server Port- Es el puerto al que ab se está conectando. Si no se proporciona ningún puerto en la línea de comando, se establecerá de forma predeterminada en 80 para http y 443 para https.
SSL/TLS Protocol- Este es el parámetro de protocolo negociado entre el cliente y el servidor. Esto solo se imprimirá si se utiliza SSL.
Document Path - Este es el URI de solicitud analizado desde la cadena de línea de comando.
Document Length- Es el tamaño en bytes del primer documento devuelto correctamente. Si la longitud del documento cambia durante la prueba, la respuesta se considera un error.
Concurrency Level - Este es el número de clientes concurrentes (equivalente a navegadores web) usados durante la prueba.
Time Taken for Tests - Este es el tiempo transcurrido desde el momento en que se crea la primera conexión de socket hasta el momento en que se recibe la última respuesta.
Complete Requests - El número de respuestas exitosas recibidas.
Failed Requests- El número de solicitudes que se consideraron fallidas. Si el número es mayor que cero, se imprimirá otra línea que muestra el número de solicitudes que fallaron debido a la conexión, lectura, longitud de contenido incorrecta o excepciones.
Total Transferred- El número total de bytes recibidos del servidor. Este número es esencialmente el número de bytes enviados a través del cable.
HTML Transferred- El número total de bytes de documentos recibidos del servidor. Este número excluye los bytes recibidos en los encabezados HTTP.
Requests per second- Este es el número de solicitudes por segundo. Este valor es el resultado de dividir el número de solicitudes por el tiempo total empleado.
Time per request- El tiempo medio empleado por solicitud. El primer valor se calcula con la fórmula de concurrencia * timetaken * 1000 / done, mientras que el segundo valor se calcula con la fórmula timetaken * 1000 / done
Transfer rate - La tasa de transferencia calculada por la fórmula totalread / 1024 / timetaken.
Análisis rápido de la salida de prueba de carga
Habiendo aprendido sobre los encabezados de los valores de salida del comando ab, intentemos analizar y comprender los valores de salida para nuestra prueba inicial:
La organización de Apache está utilizando su propio software de servidor web: Apache (versión 2.4.7)
El servidor está escuchando en el puerto 443 debido a https. Si hubiera sido http, habría sido 80 (predeterminado).
El total de datos transferidos es de 58769 bytes para 100 solicitudes.
Prueba completada en 1.004 segundos. No hay solicitudes fallidas.
Solicitudes por segundo: 99,56. Este se considera un número bastante bueno.
Tiempo por solicitud: 100,444 ms (para 10 solicitudes simultáneas). Entonces, en todas las solicitudes, es 100.444 ms / 10 = 10.044 ms.
Tasa de transferencia: 1338,39 [Kbytes / seg] recibidos.
En las estadísticas de tiempo de conexión, se puede observar que muchas solicitudes tuvieron que esperar unos segundos. Esto puede deberse a que el servidor web apache pone las solicitudes en cola de espera.
En nuestra primera prueba, probamos una aplicación (es decir, www.apache.org) alojada en un servidor diferente. En la parte posterior del tutorial, probaremos nuestras aplicaciones web de muestra alojadas en el mismo servidor desde el que ejecutaremos las pruebas ab. Esto es para facilitar el aprendizaje y la demostración. Idealmente, el nodo principal y el nodo de prueba deben ser diferentes para una medición precisa.
Para aprender mejor ab, debe comparar y observar cómo varían los valores de salida para diferentes casos a medida que avanzamos en este tutorial.
Trazar la salida de Apache Bench
Aquí trazaremos el resultado relevante para ver cuánto tiempo tarda el servidor a medida que aumenta el número de solicitudes. Para eso, agregaremos el-g opción en el comando anterior seguido del nombre del archivo (aquí out.data) en el que se guardarán los datos de salida ab -
$ ab -n 100 -c 10 -g out.data https://www.apache.org/Veamos ahora el out.data antes de crear una trama -
$ less out.dataOutput
starttime seconds ctime dtime ttime wait
Tue May 30 12:11:37 2017 1496160697 40 38 77 13
Tue May 30 12:11:37 2017 1496160697 42 38 79 13
Tue May 30 12:11:37 2017 1496160697 41 38 80 13
...Entendamos ahora los encabezados de columna en el out.data archivo -
starttime - Esta es la fecha y hora en que comenzó la llamada.
seconds - Igual que la hora de inicio pero en el formato de marca de tiempo de Unix (fecha -d @ 1496160697 devuelve la salida de la hora de inicio).
ctime - Este es el tiempo de conexión.
dtime - Este es el tiempo de procesamiento.
ttime - Este es el tiempo total (es la suma de ctime y dtime, matemáticamente ttime = ctime + dtime).
wait - Este es el tiempo de espera.
Para obtener una visualización gráfica de cómo se relacionan estos elementos múltiples entre sí, eche un vistazo a la siguiente imagen:
Si estamos trabajando en una terminal o donde los gráficos no están disponibles, gnuplotes una gran opción. Lo entenderemos rápidamente siguiendo los siguientes pasos.
Instalemos y lancemos gnuplot -
$ sudo apt-get install gnuplot
$ gnuplotOutput
G N U P L O T
Version 4.6 patchlevel 6 last modified September 2014
Build System: Linux x86_64
Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others
gnuplot home: http://www.gnuplot.info
faq, bugs, etc: type "help FAQ"
immediate help: type "help" (plot window: hit 'h')
Terminal type set to 'qt'
gnuplot>Como estamos trabajando sobre el terminal y suponiendo que los gráficos no estén disponibles, podemos elegir el terminal tonto que dará salida en ASCII sobre el propio terminal. Esto nos ayuda a tener una idea de cómo se ve nuestra trama con esta herramienta rápida. Preparemos ahora la terminal para el diagrama ASCII.
gnuplot> set terminal dumbOutput
Terminal type set to 'dumb'
Options are 'feed size 79, 24'Como, nuestra terminal gnuplot ahora está lista para el trazado ASCII, tracemos los datos del out.data archivo -
gnuplot> plot "out.data" using 9 w lOutput
1400 ++-----+------+-----+------+------+------+------+-----+------+-----++
+ + + + + + +"out.data" using 9 ****** +
| |
1200 ++ ********************************************
| ******************* |
1000 ++ * ++
| * |
| * |
800 ++ * ++
| * |
| * |
600 ++ * ++
| * |
| * |
400 ++ * ++
| * |
200 ++ * ++
| * |
+**** + + + + + + + + + +
0 ++-----+------+-----+------+------+------+------+-----+------+-----++
0 10 20 30 40 50 60 70 80 90 100Hemos graficado el ttime, tiempo total (en ms) de la columna 9, con respecto al número de solicitudes. Podemos notar que para las peticiones de diez iniciales, el tiempo total fue en los cerca de 100 ms, para los próximos 30 peticiones (de 10 º a 40 º ), aumentó a 1100 ms, y así sucesivamente. Tu trama debe ser diferente dependiendo de tuout.data.
En el capítulo anterior, entendimos el uso básico de Apache Bench para probar un sitio web de terceros. En esta sección, utilizaremos esta herramienta para probar una aplicación web en nuestro propio servidor. Para mantener el tutorial autónomo en la medida de lo posible, hemos optado por instalar una aplicación de Python con fines de demostración; puede elegir cualquier otro lenguaje como PHP o Ruby dependiendo de su nivel de experiencia.
Instalación de Python
Generalmente, Python se instala de forma predeterminada en los servidores Linux.
Instalación de Bottle Framework y creación de una aplicación simple
Bottle es un micro-framework escrito en Python para crear aplicaciones web, y pip es un administrador de paquetes de Python. Escriba el siguiente comando en la terminal para instalar Bottle -
$ sudo apt-get install python-pip
$ sudo pip install bottleCreemos ahora una pequeña aplicación Bottle. Para eso, cree un directorio y muévase dentro de él:
$ mkdir webapp
$ cd webappCrearemos un nuevo script de Python, app.py, dentro del directorio de aplicaciones web -
$ vim app.pyAhora, escriba el siguiente código en el archivo app.py:
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello')
def hello():
return "Hello World!"
run(app, host = 'localhost', port = 8080)Cuando haya agregado las líneas anteriores, guarde y cierre el archivo. Una vez guardado el archivo, podemos ejecutar el script de Python para iniciar la aplicación:
$ python app.pyOutput
Bottle v0.12.7 server starting up (using WSGIRefServer())...
Listening on http://localhost:8080/
Hit Ctrl-C to quit.Este resultado muestra que nuestra aplicación se está ejecutando en la máquina local en el host http://localhost y escuchando en el puerto 8080.
Comprobemos si nuestra aplicación responde correctamente a las solicitudes HTTP. Como este terminal no puede tomar ninguna entrada sin dejar de servir la aplicación Bottle, debemos iniciar sesión en nuestro VPS con otro terminal. Después de iniciar sesión en el VPS con otro terminal, puede navegar a su aplicación escribiendo el siguiente código en el nuevo terminal.
$ lynx http://localhost:8080/Lynx es un navegador de línea de comandos y generalmente se instala de forma predeterminada en varias distribuciones de Linux como Debian y Ubuntu. Si ve el siguiente resultado, significa que su aplicación está funcionando bien.
Output
Si ve el resultado anterior, significa que nuestra aplicación está activa y lista para la prueba.
Prueba de la aplicación con Development Web Server
Tenga en cuenta que hay un error en ab y que no puede probar la aplicación en el host local. Entonces, cambiaremos el host de localhost a 127.0.0.1 en el archivo app.py. Entonces el archivo cambiará a lo siguiente:
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello')
def hello():
return "Hello World!"
run(app, host = '127.0.0.1', port = 8080)Probemos ahora nuestra aplicación escribiendo el siguiente comando en la misma terminal en la que se ejecutó el comando lynx:
$ ab -n 100 -c 10 http://127.0.0.1:8080/helloOutput
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: WSGIServer/0.1
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /hello
Document Length: 12 bytes
Concurrency Level: 10
Time taken for tests: 0.203 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 16500 bytes
HTML transferred: 1200 bytes
Requests per second: 493.78 [#/sec] (mean)
Time per request: 20.252 [ms] (mean)
Time per request: 2.025 [ms] (mean, across all concurrent requests)
Transfer rate: 79.56 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 0
Processing: 1 6 28.2 2 202
Waiting: 1 6 28.2 2 202
Total: 1 6 28.2 2 202
Percentage of the requests served within a certain time (ms)
50% 2
66% 2
75% 2
80% 2
90% 2
95% 2
98% 202
99% 202
100% 202 (longest request)Mientras que la salida en el primer terminal será (100 veces) como sigue:
...
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
...Puede observar cómo han cambiado los distintos valores del resultado ab en comparación con la prueba inicial.
Prueba de la aplicación con un servidor web multiproceso
En las pruebas anteriores de ab, hemos utilizado el servidor web predeterminado incluido en el marco Bottle.
Ahora cambiaremos el servidor web predeterminado de un solo subproceso por uno de múltiples subprocesos. Por lo tanto, instalemos una biblioteca de servidor web multiproceso comocherrypy o gunicorny dile a Bottle que lo use. Hemos elegido gunicorn para el propósito de demostración aquí (también puede elegir otro):
$ sudo apt-get install gunicornY modificar el archivo, es decir, cambiar del servidor web predeterminado a gunicorn -
...
run(server = 'gunicorn'...)
...Probemos la aplicación en la segunda terminal.
$ ab -n 100 -c 10 http://127.0.0.1:8080/helloOutput
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: gunicorn/19.0.0
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /hello
Document Length: 12 bytes
Concurrency Level: 10
Time taken for tests: 0.031 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 17200 bytes
HTML transferred: 1200 bytes
Requests per second: 3252.77 [#/sec] (mean)
Time per request: 3.074 [ms] (mean)
Time per request: 0.307 [ms] (mean, across all concurrent requests)
Transfer rate: 546.36 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.9 0 4
Processing: 1 2 0.7 3 4
Waiting: 0 2 0.8 2 3
Total: 2 3 0.6 3 5
WARNING: The median and mean for the initial connection time are not within a normal
deviation These results are probably not that reliable.
WARNING: The median and mean for the processing time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 4
95% 5
98% 5
99% 5
100% 5 (longest request)Observe cómo las solicitudes por segundo aumentaron de 493 a 3252. Significa que gunicorn es adecuado como servidor de producción para aplicaciones de Python.
En este capítulo, aprenderemos a probar varias URL al mismo tiempo. Para eso, necesitaremos editar nuestro archivo de aplicación, app.py para incluir dos URL:
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello1')
def hello():
return "Hello World! It is first URL."
@app.route('/hello2')
def hello():
return "Hello World! It is second URL."
run(app,server = 'gunicorn',host = '127.0.0.1', port = 8080)Creación de un script de shell simple
Puede hacer esto creando un script de shell, con múltiples llamadas ab. Cree un archivo test.sh y agréguele las siguientes líneas:
ab -n 100 -c 10 http://127.0.0.1:8080/hello1
ab -n 100 -c 10 http://127.0.0.1:8080/hello2Cuando haya agregado las líneas anteriores, guarde y cierre el archivo. Haga que el archivo sea ejecutable -
chmod u+x test.shEjecutemos ahora el script -
./test.shPara evitar la repetición y el propósito de la claridad, mostraremos solo lo relevante de la salida ab, indicando con puntos qué parte se ha omitido, como se muestra a continuación.
Salida
.
.
.
Document Path: /hello1
Document Length: 732 bytes
Concurrency Level: 10
Time taken for tests: 0.040 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Total transferred: 90000 bytes
HTML transferred: 73200 bytes
Requests per second: 2496.13 [#/sec] (mean)
Time per request: 4.006 [ms] (mean)
Time per request: 0.401 [ms] (mean, across all concurrent requests)
Transfer rate: 2193.87 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.8 0 3
Processing: 1 3 1.0 4 5
Waiting: 0 3 1.2 4 4
Total: 1 4 0.6 4 5
WARNING: The median and mean for the processing time are not within a normal deviation
These results are probably not that reliable.
.
.
.Shell Script para guardar la salida de Apache Bench en un archivo
Puede guardar la salida de Apache Bench en un archivo creando un script de shell, con múltiples llamadas ab. Al final de cada línea, coloque un&;esto hace que el comando se ejecute en segundo plano y permite que el siguiente comando comience su ejecución. También querrá redirigir la salida a un archivo para cada URL usando <nombre de archivo>. Por ejemplo, nuestro archivo test.sh se verá así después de la modificación:
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello1 > test1.txt &
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello2 > test2.txt &Aquí, test1.txt y test2.txt son los archivos para guardar los datos de salida.
Puede verificar que el script anterior haya creado dos archivos, test1.txt y test2.txt, que contienen la salida ab para las respectivas URL:
$ ls -lSalida
...
-rw-r--r-- 1 root root 5225 May 30 12:11 out.data
-rwxr--r-- 1 root root 118 Jun 10 12:24 test.sh
-rw-r--r-- 1 root root 1291 Jun 10 12:31 test1.txt
-rwxr--r-- 1 root root 91 Jun 10 13:22 test2.sh
-rw-r--r-- 1 root root 1291 Jun 10 12:31 test2.txt
...Situación de vigilancia
Mientras usa ab, debe estar alerta a la prueba fallida sin previo aviso. Por ejemplo, si comprueba una URL incorrecta, puede obtener algo similar a lo siguiente (aquí hemos cambiado deliberadamente el puerto).
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:805/Salida
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software:
Server Hostname: 127.0.0.1
Server Port: 805
Document Path: /
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.002 seconds
Complete requests: 100
Failed requests: 150
(Connect: 0, Receive: 100, Length: 0, Exceptions: 50)
Keep-Alive requests: 0
Total transferred: 0 bytes
HTML transferred: 0 bytes
Requests per second: 44984.26 [#/sec] (mean)
Time per request: 0.222 [ms] (mean)
Time per request: 0.022 [ms] (mean, across all concurrent requests)
Transfer rate: 0.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 0 0 0.2 0 0
Waiting: 0 0 0.0 0 0
Total: 0 0 0.2 0 0
Percentage of the requests served within a certain time (ms)
50% 0
66% 0
75% 0
80% 0
90% 0
95% 0
98% 0
99% 0
100% 0 (longest request)En este capítulo, comprenderemos la preparación necesaria para probar páginas dinámicas. Una página web dinámica del lado del servidor es una página web cuya construcción está controlada por un servidor de aplicaciones que procesa los scripts del lado del servidor. El banco de apache solo puede probar la carga de la página web dinámica del lado del servidor.
Nivel de simultaneidad y número total de solicitudes
El nivel de simultaneidad debe ser menor que el número total de solicitudes.
$ ab -l -r -n 30 -c 80 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Output
ab: Cannot use concurrency level greater than total number of requests
Usage: ab [options] [http[s]://]hostname[:port]/pathUso de banderas
En esta sección, describiremos el uso de algunos indicadores importantes con el comando ab. Usaremos los términos, opciones y banderas, indistintamente.
Verboso -v
La opción detallada se puede utilizar para analizar y depurar si existen varias solicitudes fallidas. Una indicación común de falla de la prueba de carga es que la prueba termina muy rápido y da un buen número de solicitud por valor de segundo. Pero será un punto de referencia incorrecto. Para identificar el éxito o el fracaso, puede utilizar el-v 2opción que volcará el cuerpo y el encabezado de cada respuesta en la salida del terminal. El siguiente comando describe un caso de uso:
$ ab -n 1 -v 2 http://www.generic-example-URL.com/Output
LOG: header received:
HTTP/1.0 200 OK
…
Content-Length: 2548687Por supuesto, si está probando respuestas variables o devolviendo códigos HTTP que no sean 200 en caso de cualquier error, simplemente debe ignorar la verificación de longitud con el -lopción. Pronto veremos HTTP no 200 cuando lancemos una aplicación web2py en los capítulos siguientes.
Mantener vivo -k
Cuando el cliente envía una solicitud HTTP, se establece la conexión con el servidor, el servidor envía la respuesta y la conexión se cierra después de enviar la solicitud. Este ciclo continúa con cada solicitud. Sin embargo, con la configuración de mantener vivo (también conocida como conexiones persistentes), el cliente mantiene abierta una conexión TCP subyacente para facilitar múltiples solicitudes y respuestas; esto elimina el lento y costoso tiempo de inicialización de la conexión que de otro modo estaría presente.
Longitud variable del documento -l
Si la página web es de longitud variable, entonces debería hacer uso de la opción -l. Apache Bench no informa errores si la longitud de las respuestas no es constante. Esto puede resultar útil para páginas dinámicas.
Uso de la opción -r
¿Cómo forzar a ab a no salir al recibir errores? Deberías usar la opción-r. Sin esta opción, su prueba puede fallar tan pronto como cualquier solicitud llegue al error de socket. Sin embargo, con esta opción, los errores se informarán en el encabezado de errores fallidos, pero la prueba continuará hasta el final.
Uso de la opción -H
Esta opción se utiliza para agregar una línea de encabezado arbitraria. El argumento suele tener la forma de una línea de encabezado válida, que contiene un par de valor de campo separado por dos puntos (es decir, "Aceptar-Codificación: zip / zop; 8 bits").
Uso de la opción -C
En la siguiente sección, aprenderemos en detalle cómo usar las opciones anteriores en combinación con la opción de usar el valor de la cookie, es decir, el -Copción. La opción -C suele tener la forma dename = valuepar. Este campo se puede repetir.
Uso de cookies de sesión con Apache Bench
Para comprender cómo usar la cookie con Apache Bench, necesitamos una página web que intente configurar una cookie. Un muy buen ejemplo es la aplicación web2py, que es un framework web de Python.
Instalación de web2py
Vamos a instalar rápidamente otra aplicación de Python, web2py. Puede leer más sobre cómo usarlo en Web2py Framework Overview .
Python generalmente se instala de forma predeterminada en los servidores Ubuntu y Debian. Por lo tanto, ya se cumple un requisito para ejecutar web2py correctamente.
Sin embargo, necesitamos instalar el paquete de descompresión para extraer los archivos fuente de web2py del archivo zip que descargaremos.
$ sudo apt-get update
$ sudo apt-get install unzipConsigamos el framework web2py del sitio web del proyecto. Descargaremos esto en nuestra carpeta de inicio -
$cd ~
$ wget http://www.web2py.com/examples/static/web2py_src.zipAhora, podemos descomprimir el archivo que acabamos de descargar y movernos dentro -
$ unzip web2py_src.zip
$ cd web2pyPara ejecutar web2py, no es necesario instalarlo. Una vez que esté dentro del directorio web2py, puede ejecutarlo escribiendo el siguiente comando:
$python web2py.pySi todo funciona correctamente, verá el siguiente resultado en el que se le pedirá que elija una contraseña para la interfaz de usuario administrativa:
web2py Web Framework
Created by Massimo Di Pierro, Copyright 2007-2017
Version 2.14.6-stable+timestamp.2016.05.10.00.21.47
Database drivers available: sqlite3, imaplib, pymysql, pg8000
WARNING:web2py:GUI not available because Tk library is not installed
choose a password:
please visit:
http://127.0.0.1:8000/
use "kill -SIGTERM 23904" to shutdown the web2py serverSin embargo, debe tener en cuenta el hecho de que solo se puede acceder a la interfaz web iniciada en la máquina local.
De la salida, puede comprender que para detener el servidor web, tendrá que escribir "CTRL-C" en la terminal instantánea. Por otro lado, para detener el servidor web2py en el otro terminal relacionado con el mismo VPS, puede insertar el comando kill -SIGTERM <PID>, donde <PID> es el ID de proceso del servidor web2py, que en este caso es 23904.
Cookie de sesión de web2py
Si solo un usuario que ha iniciado sesión puede acceder a una página, no se puede acceder directamente desde la página de inicio de sesión, en ese caso puede utilizar el -Cbandera. Esta bandera define una cookie para el comando ab. Pero debe obtener el valor de la cookie de identificación de sesión de una sesión válida. ¿Cómo conseguir eso? Varios tutoriales en línea lo guiarán hacia las herramientas de desarrollo del navegador Chrome (o Mozilla). Pero en nuestro caso de prueba, como la aplicación está disponible solo en la línea de comandos, usaremos el navegador lynx para obtener el valor.
Primero obtengamos el valor de la cookie de una sesión. Abra otra terminal y escriba el siguiente comando:
$ lynx http://127.0.0.1:8000/En respuesta al comando anterior, lynx le pedirá permiso para aceptar la cookie del servidor web2py como se muestra en la imagen a continuación.
Anote el valor de la cookie antes de escribir ypara aceptar la cookie. Ahora el terminal se verá similar a la siguiente imagen: ¡sitio web en el terminal!
Habiendo obtenido el valor de la cookie, ahora ejecutaremos la prueba ab. Para eso tendremos que abrir la tercera terminal (ver la imagen a continuación) -
Ahora, usemos la bandera -C en la tercera terminal -
$ ab -n 100 -c 10 -C session_name = 127.0.0.1-643dad04-3c34 http://127.0.0.1:8000/Salida
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: 66 bytes
Concurrency Level: 10
Time taken for tests: 0.051 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 1968.12 [#/sec] (mean)
Time per request: 5.081 [ms] (mean)
Time per request: 0.508 [ms] (mean, across all concurrent requests)
Transfer rate: 532.39 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.9 2 4
Processing: 0 3 0.9 3 5
Waiting: 0 2 1.1 2 4
Total: 4 5 0.7 5 7
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 5
80% 6
90% 6
95% 6
98% 7
99% 7
100% 7 (longest request)De la salida anterior, observamos varios puntos. Primero, web2py usa el servidor web Rocket . También notamos que estamos recibiendo 'Respuestas que no son 2xx' además de los encabezados discutidos previamente en el resultado. En general, el protocolo Http responde a una solicitud usando un código de respuesta, y cualquier cosa dentro del rango de 200 significa 'bien', y el resto corresponde a algún problema. Por ejemplo, los 400 son errores relacionados con los recursos, como el archivo 404 no encontrado. 500 corresponden a errores del servidor. En nuestro caso instantáneo, no hay ningún error en ninguna parte excepto cuando estamos usando la opción -C. Puede suprimirse usando la opción -l como ya se describió.
Comprobando la página de administración
En esta sección, entenderemos cómo verificar la página de administración. Para fines de comparación, probemos otra URL de la aplicación web2py:
$ ab -n 100 -c 10 session_name = 127.0.0.1-643dad04-3c34 http://127.0.0.1:8000/adminSalida
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /admin
Document Length: 8840 bytes
Concurrency Level: 10
Time taken for tests: 2.077 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 926700 bytes
HTML transferred: 884000 bytes
Requests per second: 48.14 [#/sec] (mean)
Time per request: 207.749 [ms] (mean)
Time per request: 20.775 [ms] (mean, across all concurrent requests)
Transfer rate: 435.61 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.2 0 12
Processing: 62 204 52.2 199 400
Waiting: 61 203 52.0 199 400
Total: 62 205 54.3 199 411
Percentage of the requests served within a certain time (ms)
50% 199
66% 211
75% 220
80% 226
90% 264
95% 349
98% 381
99% 411
100% 411 (longest request)En particular, debe tener en cuenta las estadísticas respectivas en la sección "Tiempos de conexión" y "Porcentaje de las solicitudes atendidas ..." de http://127.0.0.1:8000/ y http://127.0.0.1:8000/admin. Hay una gran diferencia.
Uso de la opción Timelimit
Generalmente, la opción Timelimit es complicada. Entendamos esto del manual de ab , que es bastante explicativo:
-t timelimit
Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally.
Use this to benchmark the server within a fixed total amount of time.
Per default there is no timelimit.Hagamos una prueba con esta opción. Anotaremos nuestras observaciones después de pasar por la salida:
$ ab -n 100 -c 10 -t 60 http://127.0.0.1:8000/Salida
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: 66 bytes
Concurrency Level: 10
Time taken for tests: 22.547 seconds
Complete requests: 50000
Failed requests: 0
Non-2xx responses: 50000
Total transferred: 13850000 bytes
HTML transferred: 3300000 bytes
Requests per second: 2217.61 [#/sec] (mean)
Time per request: 4.509 [ms] (mean)
Time per request: 0.451 [ms] (mean, across all concurrent requests)
Transfer rate: 599.88 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 0.8 2 8
Processing: 0 2 3.2 2 218
Waiting: 0 2 3.2 2 218
Total: 2 4 3.1 4 220
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 5
90% 5
95% 5
98% 7
99% 8
100% 220 (longest request)Observe que el resultado muestra que esta opción anula el número de solicitudes especificadas por el -nopción y continúa hasta las solicitudes de 50K. Sin embargo, como las solicitudes se manejaron muy rápido, ab ha terminado tan pronto como se logró la marca de 50k, en 22 segundos (consulte el encabezado Tiempo de prueba) en el presente caso.
Puede probar el mismo comando reemplazando http://127.0.0.1:8000/ con http://127.0.0.1:8000/admin (asumiendo que es nuestra aplicación web2py) o un sitio web de un tercero como https://www.apache.org/, observe la diferencia en las estadísticas.
Lista de verificación antes de realizar la prueba de carga
Hay algunas comprobaciones que le ayudarán a ejecutar correctamente la prueba y medir el rendimiento con precisión. Tenga en cuenta las siguientes condiciones antes de realizar la prueba de carga:
Asegúrese de que no se cargue ningún módulo de Python adicional.
Para evitar el agotamiento del puerto TCP / IP, normalmente debe esperar de 2 a 3 minutos antes de pasar a otra prueba ab.
Asegúrese de que el número de conexiones simultáneas sea menor que el de Apache Worker Threads.
Debe reiniciar el servidor antes de realizar otra prueba, si Apache o Python fallan.
En este capítulo, describiremos las diversas combinaciones de -n y -c con las banderas importantes para aumentar gradualmente la carga en su servidor web.
Debe centrarse principalmente en cómo cambian las siguientes métricas a medida que aumenta la carga:
- Solicitudes por segundo
- Tiempos de conexión (ms)
- Porcentaje de solicitudes atendidas en un tiempo determinado (ms)
También debe observar el valor de umbral cuando el servidor comienza a atascarse y comienza a recibir solicitudes fallidas.
1 usuario simultáneo que realiza 100 visitas a la página
Hagamos 100 cargas de página secuenciales por un solo usuario:
$ ab -l -r -n 100 -c 1 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Salida
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: Variable
Concurrency Level: 1
Time taken for tests: 0.045 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Keep-Alive requests: 0
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 2206.24 [#/sec] (mean)
Time per request: 0.453 [ms] (mean)
Time per request: 0.453 [ms] (mean, across all concurrent requests)
Transfer rate: 596.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 0 0 0.0 0 0
Waiting: 0 0 0.0 0 0
Total: 0 0 0.0 0 1
Percentage of the requests served within a certain time (ms)
50% 0
66% 0
75% 0
80% 0
90% 1
95% 1
98% 1
99% 1
100% 1 (longest request)5 usuarios simultáneos, cada uno con 10 visitas a la página
Este caso corresponde a una carga máxima en un sitio web que recibe alrededor de 50.000 visitas al mes.
$ ab -l -r -n 10 -c 5 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/En las siguientes salidas subsiguientes, omitiremos el encabezado común por motivos de claridad.
Salida
...
Requests per second: 2009.24 [#/sec] (mean)
Time per request: 2.488 [ms] (mean)
Time per request: 0.498 [ms] (mean, across all concurrent requests)
Transfer rate: 543.52 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.5 1 2
Processing: 0 1 0.5 1 2
Waiting: 0 1 0.5 1 1
Total: 2 2 0.4 3 3
ERROR: The median and mean for the total time are more than twice the standard
deviation apart. These results are NOT reliable.
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 3
95% 3
98% 3
99% 3
100% 3 (longest request)10 usuarios simultáneos, cada uno con 10 visitas a la página
Esta prueba corresponde a cargas de 100 páginas por 10 usuarios concurrentes diferentes, cada usuario realiza cargas de 10 páginas secuenciales.
$ ab -r -n 10 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Salida
...
Requests per second: 2225.68 [#/sec] (mean)
Time per request: 4.493 [ms] (mean)
Time per request: 0.449 [ms] (mean, across all concurrent requests)
Transfer rate: 602.07 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 1.0 2 3
Waiting: 0 1 1.0 2 3
Total: 4 4 0.3 4 4
WARNING: The median and mean for the waiting time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 4
95% 4
98% 4
99% 4
100% 4 (longest request)20 usuarios simultáneos, cada uno con 20 visitas a la página
Esta prueba corresponde a cargas de 400 páginas por 20 usuarios concurrentes diferentes, cada usuario está haciendo cargas de 20 páginas secuenciales.
$ ab -r -n 20 -c 20 -k -H “Accept-Encoding: gzip, deflate” http://127.0.0.1:8000/Salida
...
Requests per second: 1619.96 [#/sec] (mean)
Time per request: 12.346 [ms] (mean)
Time per request: 0.617 [ms] (mean, across all concurrent requests)
Transfer rate: 438.21 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 6 2.3 6 10
Processing: 1 5 2.9 5 10
Waiting: 0 5 2.9 5 9
Total: 10 11 0.6 11 12
Percentage of the requests served within a certain time (ms)
50% 11
66% 11
75% 12
80% 12
90% 12
95% 12
98% 12
99% 12
100% 12 (longest request)30 usuarios concurrentes cada uno con 30 visitas a la página
Esta prueba corresponde a 900 páginas cargadas por 30 usuarios concurrentes diferentes, cada usuario está haciendo 30 cargas de páginas secuenciales.
$ ab -r -n 30 -c 30 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Salida
...
Requests per second: 2283.45 [#/sec] (mean)
Time per request: 13.138 [ms] (mean)
Time per request: 0.438 [ms] (mean, across all concurrent requests)
Transfer rate: 617.69 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 6 2.7 6 11
Processing: 1 6 3.1 6 11
Waiting: 0 5 3.2 5 10
Total: 11 12 0.5 12 13
Percentage of the requests served within a certain time (ms)
50% 12
66% 12
75% 12
80% 12
90% 13
95% 13
98% 13
99% 13
100% 13 (longest request)Ahora hemos aprendido cómo aumentar la carga gradualmente en el sitio web y probar su rendimiento.
En este capítulo, compararemos las salidas con y sin banderas. Veamos cómo el uso de indicadores adecuados puede aumentar el rendimiento de su aplicación web. Antes de eso, debemos entender cómo si su aplicación es simple, es posible que no note la diferencia. Como es el caso de nuestra sencilla aplicación, con banderas y sin banderas. Luego realizaremos la misma prueba conhttps://www.apache.org/ URL y ver la diferencia.
Probando nuestra aplicación sin banderas
En esta sección, entenderemos cómo probar nuestra aplicación sin banderas.
$ ab -n 100 -c 10 http://127.0.0.1:8000/Salida
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.244 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Keep-Alive requests: 0
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 2208.77 [#/sec] (mean)
Time per request: 4.527 [ms] (mean)
Time per request: 0.453 [ms] (mean, across all concurrent requests)
Transfer rate: 597.49 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 0.7 2 4
Waiting: 0 2 1.0 2 3
Total: 4 4 0.3 4 5
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 5
80% 5
90% 5
95% 5
98% 5
99% 5
100% 5 (longest request)Probando nuestra aplicación con banderas
En esta sección, entenderemos cómo probar nuestra aplicación con banderas.
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Salida
...
Requests per second: 2277.07 [#/sec] (mean)
Time per request: 4.392 [ms] (mean)
Time per request: 0.439 [ms] (mean, across all concurrent requests)
Transfer rate: 615.97 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 0.7 2 4
Waiting: 0 2 1.0 2 3
Total: 4 4 0.2 4 5
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 5
95% 5
98% 5
99% 5
100% 5 (longest request)Simplemente podemos señalar que no hay mucha diferencia entre las estadísticas de salida.
Probar el sitio web de la organización Apache sin banderas
Veamos ahora cómo probar el sitio web de la organización Apache sin banderas.
$ ab -n 100 -c 10 http://www.apache.org/Salida
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.apache.org (be patient).....done
Server Software: Apache/2.4.7
Server Hostname: www.apache.org
Server Port: 80
Document Path: /
Document Length: 58433 bytes
Concurrency Level: 10
Time taken for tests: 1.498 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 5877500 bytes
HTML transferred: 5843300 bytes
Requests per second: 66.74 [#/sec] (mean)
Time per request: 149.840 [ms] (mean)
Time per request: 14.984 [ms] (mean, across all concurrent requests)
Transfer rate: 3830.58 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 12 110 295.2 12 1012
Processing: 37 38 0.5 38 39
Waiting: 12 13 0.3 13 15
Total: 49 147 295.4 50 1051
Percentage of the requests served within a certain time (ms)
50% 50
66% 50
75% 50
80% 50
90% 816
95% 1050
98% 1051
99% 1051
100% 1051 (longest request)Prueba del sitio web de la organización Apache con banderas
Probemos ahora el sitio web de la organización Apache con banderas.
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://www.apache.org/Salida
...
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.357 seconds
Complete requests: 100
Failed requests: 0
Keep-Alive requests: 100
Total transferred: 1358510 bytes
HTML transferred: 1317700 bytes
Requests per second: 280.28 [#/sec] (mean)
Time per request: 35.678 [ms] (mean)
Time per request: 3.568 [ms] (mean, across all concurrent requests)
Transfer rate: 3718.41 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.7 0 12
Processing: 14 17 21.3 15 227
Waiting: 14 17 21.3 14 227
Total: 14 18 21.5 15 227
Percentage of the requests served within a certain time (ms)
50% 15
66% 15
75% 15
80% 15
90% 27
95% 28
98% 29
99% 227
100% 227 (longest request)Simplemente puede observar cómo aumentó la solicitud por segundo con el uso de banderas. En el presente caso, se debe particularmente al uso de-H "Accept-Encoding: gzip, desinflar porque esta bandera le dice al servidor Apache que atienda las solicitudes en gzipped formato.
Considerando los resultados de Apache Bench
Es necesario considerar algunos puntos importantes cuando se trata de los resultados de Apache Bench. Esto nos ayudará a diseñar nuestra estrategia general para eliminar los cuellos de botella en nuestra aplicación y mejorar su rendimiento.
Necesitamos solicitudes por segundo. Esto nos da una idea de lo bien que está funcionando la configuración de nuestro servidor web; cuanto mayor sea el número, mejor será el rendimiento. Luego vienen los Tiempos de conexión (ms) y el Porcentaje de solicitudes atendidas. Es posible que deba modificar la configuración de su servidor web para cambiar estas métricas al rendimiento deseado.
Compruebe si hay errores en los registros de errores o registros (generales) de Apache o del servidor web utilizado. A medida que aumente su carga, las cosas comenzarán a ahogarse: comenzarán a surgir problemas de memoria. Muchos scripts de Python comenzarán a fallar si no se escriben teniendo en cuenta la simultaneidad.
¿Necesita averiguar cuál es el valor de simultaneidad crítico por encima del cual su servidor web falla y / o se agota el tiempo de espera? Normalmente, esto debería suceder a un nivel de concurrencia bastante alto. Si este valor es bajo, algo anda mal y necesita ajustar estos valores más bajos o más altos.
Conclusión
En este tutorial, aprendimos cómo se puede usar Apache Bench para probar la carga de cualquier sitio web o aplicación web. Apache Bench puede ser una herramienta muy valiosa para determinar cómo se debe mejorar la configuración de su servidor de aplicaciones web, para reducir los cuellos de botella y aumentar el rendimiento. Ahora que está familiarizado con el uso básico de Apache Bench, puede comenzar creando nuevos planes de prueba para medir el rendimiento de sus aplicaciones en varios escenarios.