Preparación para probar páginas dinámicas

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]/path

Uso 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: 2548687

Por 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 unzip

Consigamos 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.zip

Ahora, podemos descomprimir el archivo que acabamos de descargar y movernos dentro -

$ unzip web2py_src.zip
$ cd web2py

Para ejecutar web2py, no es necesario instalarlo. Una vez que esté dentro del directorio web2py, puede ejecutarlo escribiendo el siguiente comando:

$python web2py.py

Si 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 server

Sin 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/admin

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:          /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.