¿Alguien puede explicar qué significan estos resultados de ApacheBench?

Question

Estoy tratando de descubrir cómo usar ApacheBench y comparar mi sitio web. Instalé el proyecto del sitio predeterminado (es ASP.NET MVC pero no dejes de leer si no eres una persona .NET).

No cambié nada. Añadir nuevo proyecto. Establezca la confuración en LIBERACIÓN. Ejecutar sin depuración. (por lo que está en modo EN VIVO). Sí, esto es con el servidor web incorporado, no con el grado de producción IIS o Apache o lo que sea.

Así que aquí están los resultados: -

C:\Temp>ab -n 1000 -c 1 http://localhost:50035/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to 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
Completed 1000 requests
Finished 1000 requests


Server Software:        ASP.NET
Server Hostname:        localhost
Server Port:            50035

Document Path:          /
Document Length:        1204 bytes

Concurrency Level:      1
Time taken for tests:   2.371 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      1504000 bytes
HTML transferred:       1204000 bytes
Requests per second:    421.73 [#/sec] (mean)
Time per request:       2.371 [ms] (mean)
Time per request:       2.371 [ms] (mean, across all concurrent requests)
Transfer rate:          619.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.1      0      16
Processing:     0    2   5.5      0      16
Waiting:        0    2   5.1      0      16
Total:          0    2   5.6      0      16

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%     16
  95%     16
  98%     16
  99%     16
 100%     16 (longest request)

C:\Temp>

Ahora, no estoy seguro exactamente qué debería estar mirando.

En primer lugar, después del número de solicitudes por segundo. Entonces, si tenemos un requisito para manejar 300 reqs / seg, entonces, ¿esto significa que maneja un promedio de 421 reqs por segundo?

En segundo lugar, ¿cuál es la razón para agregar más concurrentes? Como en, si tengo 1000 visitas en 1 concurrente, ¿cómo difiere eso de 500 en 2 concurrentes? ¿Es para probar si hay algún código que bloquee otras solicitudes?

Por último, ¿hay algo importante que me haya perdido de los resultados que deba tener en cuenta?

Gracias :)

Answer 1

  

cuál es la razón para agregar más   ¿concurrente? Como en, si tengo 1000 visitas   en 1 concurrente, ¿cómo difiere eso   a 500 en 2 concurrentes? ¿Es para probar   si hay algún código que bloquee otro   solicitudes?

Se trata un poco de eso, sí: su aplicación probablemente esté haciendo cosas donde la concurrencia puede traer problemas.

Un par de ejemplos:

• una página está intentando acceder a un archivo, bloqueándolo en el proceso; significa que si otra página tiene que acceder al mismo archivo, tendrá que esperar hasta que la primera página haya terminado de funcionar con él.
• lo mismo para el acceso a la base de datos: si una página está escribiendo en una base de datos, hay algún tipo de mecanismo de bloqueo (ya sea basado en tablas o en filas, o lo que sea, dependiendo de su DBMS)

Está bien probar con una concurrencia de uno ... Siempre y cuando su sitio web nunca tenga más de un usuario al mismo tiempo; lo cual no es realista, espero por ti.

Debe pensar cuántos usuarios estarán en el sitio al mismo tiempo, cuando esté en producción, y ajustar la concurrencia; solo recuerda que 5 usuarios al mismo tiempo en tu sitio no significa que tengas que probar con una concurrencia de 5 con ab:

• los usuarios reales esperarán un par de segundos entre cada solicitud (tiempo para leer la página, hacer clic en un enlace, ...)
• ab no espera en absoluto: cada vez que se carga una página (es decir, se completa una solicitud), se inicia otra solicitud

Además, otras dos cosas:

• ab solo prueba para una página: los usuarios reales navegarán por todo el sitio web, lo que podría causar problemas de concurrencia que no tendría al probar solo una página
• ab solo carga una página: no solicita recursos externos (piense en CSS, imágenes, JS, ...); lo que significa que tendrá muchas otras solicitudes, incluso si no es realmente costoso, cuando su sitio esté en producción.

Como nota al margen: es posible que desee echar un vistazo a otras herramientas, que pueden hacer pruebas mucho más completas, como asedio , Jmeter , o OpenSTA : ab es realmente bueno cuando quieres medir si algo que hiciste está optimizando tu página o no; pero si quieres simular " real " uso de su sitio, estos están mucho más adaptados.

Answer 2

Sí, si desea saber cuántas solicitudes por segundo puede atender su sitio, mire " Solicitudes por segundo " línea. En su caso, es realmente bastante simple, ya que ejecutó ab con concurrencia de 1. Cada solicitud, en promedio, solo tomó 2.371 ms. 421 de ellos, uno tras otro, toman 1 segundo.

Realmente deberías jugar un poco con la concurrencia para medir con precisión la capacidad de tu sitio. Hasta cierto grado de concurrencia, esperaría que el rendimiento aumentara, ya que IIS maneja múltiples solicitudes en paralelo. P.ej. si su servidor tiene múltiples CPU / núcleos. Además, si una página se basa en IO externo (servicio de nivel medio o llamadas de DB), la CPU puede funcionar en una solicitud, mientras que otra está esperando que se complete IO. En cierto punto, las solicitudes / seg se nivelarán, con una concurrencia creciente, y verá un aumento de la latencia. Aumente la concurrencia aún más y verá disminuir su rendimiento (req / seg), ya que el servidor tiene que dedicar más recursos para hacer malabarismos con todas estas solicitudes concurrentes.

Dicho todo esto, la mayoría de sus solicitudes regresan en aproximadamente 2 ms. Eso es bastante rápido, así que supongo que no está sucediendo mucho en términos de llamadas DB o de nivel medio, y su sistema probablemente esté al máximo en la CPU cuando se ejecuta la prueba (o algo está mal y falla muy rápido. ¿está seguro de que ab obtiene la página de respuesta que desea? Es decir, ¿es la página que cree que está probando 1204 bytes? Lo que trae a colación otro punto: el ab mismo también consume CPU, especialmente una vez que aumenta la concurrencia. Entonces quieres ejecutar ab en otra máquina.

Además, si su sitio realiza llamadas externas a servicios de nivel medio o bases de datos, desea ajustar su machine.config para optimizar el número de subprocesos que IIS asigna: http://support.microsoft.com/default.aspx?scid=kb;en-us;821268

Y solo una pequeña trivia: las estadísticas del tiempo necesario se realizan en incrementos de ~ 16 ms, ya que parece ser la granularidad del temporizador utilizado. Es decir. El 80% de sus respuestas no tomaron 0 ms, tomaron un tiempo & Lt; 16 ms.