php - benchmark - apache bench

Solicitudes fallidas por longitud en mi resultado de prueba de carga de ApacheBench

Question

Tengo un sitio web en PHP, Lighttpd. También utiliza MySQL en Centos 5. He probado mi PHP con el código siguiente con Apache Bench (ab). Resultó en algunos errores (solicitudes fallidas) que indicaban una longitud distinta a la normal. Estoy absolutamente seguro de que mi resultado de PHP siempre debe tener la misma longitud exacta. He revisado mis registros de Lighttpd y MySQL y los registros de errores y no tengo ningún error allí.

¿Hay alguna forma de verificar exactamente qué obtiene ab cuando el resultado tiene otra longitud o hay alguna otra manera de averiguar cuál es la causa o cuál es el resultado "malo"?

Necesito saberlo porque necesito tener un 100% de buenos resultados.

-bash-3.2# ab -n 500 -c 200 http://domain.com/test/index.php
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 domain.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Finished 500 requests
Server Software: lighttpd/1.4.20
Server Hostname: domain.com
Server Port: 80
Document Path: /test/index.php
Document Length: 15673 bytes
Concurrency Level: 200
Time taken for tests: 0.375862 seconds
Complete requests: 500
Failed requests: 499
(Connect: 0, Length: 499, Exceptions: 0)
Write errors: 0
Total transferred: 7920671 bytes
HTML transferred: 7837000 bytes
Requests per second: 1330.28 [#/sec] (mean)
Time per request: 150.345 [ms] (mean)
Time per request: 0.752 [ms] (mean, across all concurrent requests)
Transfer rate: 20579.36 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 10 9.4 6 30
Processing: 0 113 133.5 16 342
Waiting: 0 111 134.3 12 341
Total: 0 123 138.9 16 370
Percentage of the requests served within a certain time (ms)
50% 16
66% 235
75% 289
80% 298
90% 331
95% 345
98% 365
99% 368
100% 370 (longest request)

Answer 1

Ejecute ab con el parámetro -v 2 , que significa nivel de verbosidad 2. Esto volcará los encabezados de respuesta. Si sus solicitudes no utilizan codificación fragmentada, verá un encabezado de "Longitud de contenido" que indica el tamaño de cada respuesta.

gw:~$ ab -n 1 -v 2 "http://whatever.com/"
...
LOG: header received:
HTTP/1.0 200 OK
...
Content-Length: 1568399

Si sus respuestas utilizan codificación fragmentada, entonces no se conoce la longitud hasta que finalice la transferencia. Por lo general, la codificación fragmentada solo se usa para respuestas comprimidas, y ApacheBench no realiza la compresión de forma predeterminada.

Si está comprimiendo las respuestas por alguna razón, eso podría explicarlo; La longitud comprimida depende del contenido.

También puede usar curl -i y la opción --compress para ver los encabezados de respuesta a una sola solicitud con y sin compresión.

Answer 2

ab asume que todas las respuestas son iguales. Observa la longitud del contenido de la primera respuesta y luego compara otras con eso.

De la página del manual:

Document Length
This is the size in bytes of the first successfully returned document.
If the document length changes during testing, the response is
considered an error.

Así que si tu primera solicitud contiene los siguientes datos:

{"hostname":"nodecellar-1-dwfxd","serverip":"10.1.3.3"}

Y el siguiente es:

{"hostname":"nodecellar-1-dwfxd","serverip":"10.1.3.30"}

ab fallará con un error de longitud, ya que la salida es un carácter más largo.

Answer 3

Utilizar tcpdump

Abra el qty 2 terminal / shell windows o simplemente use la pantalla.

En la primera ventana, use tcpdump para capturar datos de transmisión desde / a su NIC (eth0) a un archivo:

sudo tcpdump -s 9999 -i eth0 -w myfile.txt

En la segunda ventana, dispara tu comando ab:

ab -n 500 -c 200 http://domain.com/test/index.php

Cuando haya terminado, analice el archivo con cadenas y grep:

strings myfile2.txt | grep -C 3 "200 OK"

Debería poder monitorear todos los segmentos de datos desde allí observando los resultados o grep''ing.