Apache Benchmark: concurrencia y número de solicitudes

Question

La documentación de referencia dice que la concurrencia es cuántas solicitudes se realizan simultáneamente, mientras que el número de solicitudes es el número total de solicitudes. Lo que me pregunto es, si presento 100 solicitudes en un nivel de concurrencia de 20, ¿eso significa 5 pruebas de 20 solicitudes al mismo tiempo, o 100 pruebas de 20 solicitudes al mismo tiempo cada una? Estoy asumiendo que la segunda opción, debido a los números de ejemplo que mostramos a continuación ..

me pregunto porque con frecuencia veo resultados como este en algunos blogs de prueba:

Complete requests: 1000000 
Failed requests: 2617614 

Esto parece inverosímil, ya que la cantidad de solicitudes fallidas es mayor que la cantidad total de solicitudes.

Editar: el sitio que muestra los números antes mencionados: http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php

O podría ser que se sigue intentando hasta que llega a un millón de éxitos? Hm ...

Answer 1

Significa una sola prueba con un total de 100 solicitudes, manteniendo 20 solicitudes abiertas en todo momento. Creo que la idea errónea que tiene es que todas las solicitudes toman la misma cantidad de tiempo, lo que prácticamente nunca es el caso. En lugar de emitir solicitudes en lotes de 20, ab simplemente comienza con 20 solicitudes y emite una nueva cada vez que finaliza una solicitud existente.

Por ejemplo, las pruebas con ab -n 10 -c 3 comenzaría with3 solicitudes simultáneas:

[1, 2, 3] 

Digamos # 2 acabados primera, ab lo reemplaza con una cuarta:

[1, 4, 3] 

... entonces # 1 con tal que acabe, sustituido por un quinto:

[5, 4, 3] 

... luego # 3 acabados:

[5, 4, 6] 

... y así sucesivamente, hasta la solicitud se han realizado un total de 10 solicitudes. (Como las solicitudes 8, 9 y 10 están completas, la simultaneidad se reduce a 0, por supuesto).

¿Tiene sentido?

En cuanto a su pregunta sobre por qué ve resultados con más fallas que las solicitudes totales ... No sé la respuesta a eso. No puedo decir que he visto eso. ¿Puedes publicar enlaces o casos de prueba que muestren esto?

Actualización: Al observar the source, ab seguimiento de cuatro tipos de errores que se detallan a continuación las solicitudes con error ": ..." línea:

• Conectar - (err_conn en origen) incrementa cuando falla ab para establecer la conexión HTTP
• Recibir - (err_recv en origen) incrementa cuando ab falla una lectura de la conexión falla
• longitud - (err_length en origen) aumenta cuando la longitud de la respuesta es diferente de la longitud de la primera buena resp. onse recibido.
• Excepciones - (? Por ejemplo, la conexión se mató por el servidor) (err_except en la fuente) incrementa cuando ab ve un error al sondeo de la toma de conexión

La lógica alrededor cuando éstas se producen y cómo se cuentan (y cómo se realiza el seguimiento del recuento total de bad) es, por necesidad, un poco complejo. Parece que la versión actual de ab solo debería contar una falla una vez por solicitud, pero tal vez el autor de ese artículo estaba usando una versión anterior que de alguna manera contaba más de una? Esa es mi mejor suposición.

Si logras reproducir el comportamiento, definitivamente file a bug.

Answer 2

No veo nada malo. Las solicitudes fallidas pueden incrementar más de un error cada una. Así es como funciona ab.

Hay varios búfers estáticamente declarados de longitud fija. Combinado con el análisis lento de los argumentos de la línea de comandos, los encabezados de respuesta del servidor y otras entradas externas, esto puede morderlo.

Puede observar, por ejemplo, que los resultados del nodo anterior tienen un conteo similar para 3 de los contadores de errores. Lo más probable, a partir de las 100 000 solicitudes sólo 8409 hechas fallado y no 25227.

Receive: 8409, Length: 8409, Exceptions: 8409