tool - testear servidor apache
prueba de carga ab (4)
Por favor, guíeme a través de los comandos que debería ejecutar para resolver esto.
La prueba más simple que puede hacer es realizar 1000 solicitudes, 10 a la vez (que simula aproximadamente 10 usuarios simultáneos que obtienen 100 páginas cada uno, a lo largo de la prueba).
ab -n 1000 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://www.example.com/
-n 1000 es el número de solicitudes para hacer.
-c 10 le dice a AB que haga 10 solicitudes a la vez, en lugar de 1 solicitud a la vez, para simular mejor a los visitantes concurrentes (frente a los visitantes secuenciales).
-k envía el encabezado KeepAlive , que solicita al servidor web que no cierre la conexión después de cada solicitud, sino que continúe reutilizándola.
También estoy enviando el encabezado adicional Accept-Encoding: gzip, deflate porque mod_deflate casi siempre se utiliza para comprimir el texto / html de salida 25% -75% - los efectos de los cuales no deben descartarse debido a su impacto en el rendimiento general del servidor web (es decir, puede transferir 2x los datos en la misma cantidad de tiempo, etc.).
Resultados:
Benchmarking www.example.com (be patient)
Completed 100 requests
...
Finished 1000 requests
Server Software: Apache/2.4.10
Server Hostname: www.example.com
Server Port: 80
Document Path: /
Document Length: 428 bytes
Concurrency Level: 10
Time taken for tests: 1.420 seconds
Complete requests: 1000
Failed requests: 0
Keep-Alive requests: 995
Total transferred: 723778 bytes
HTML transferred: 428000 bytes
Requests per second: 704.23 [#/sec] (mean)
Time per request: 14.200 [ms] (mean)
Time per request: 1.420 [ms] (mean, across all concurrent requests)
Transfer rate: 497.76 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 5 14 7.5 12 77
Waiting: 5 14 7.5 12 77
Total: 5 14 7.5 12 77
Percentage of the requests served within a certain time (ms)
50% 12
66% 14
75% 15
80% 16
90% 24
95% 29
98% 36
99% 41
100% 77 (longest request)
Para la interpretación más simple, ignore todo PERO esta línea:
Requests per second: 704.23 [#/sec] (mean)
Multiplícalo por 60, y tienes tus solicitudes por minuto.
Para obtener resultados del mundo real, querrás probar Wordpress en lugar de HTML estático o archivo index.php porque necesitas saber cómo funciona todo junto: incluyendo código PHP complejo y múltiples consultas MySQL ...
Por ejemplo, aquí están los resultados de probar una instalación nueva de Wordpress en el mismo sistema y entorno WAMP (estoy usando WampDeveloper, pero también hay Xampp, WampServer y otros) ...
Requests per second: 18.68 [#/sec] (mean)
¡Eso es 37 veces más lento ahora!
Después de la prueba de carga, hay varias cosas que puede hacer para mejorar el rendimiento general (Solicitudes por segundo) y también hacer que el servidor web sea más estable bajo mayor carga (por ejemplo, aumentar la -n y la -c tiende a bloquearse) Apache), que puedes leer aquí:
¿Puede alguien guiarme por el proceso de cómo puedo cargar la prueba de mi sitio web utilizando apache bench tool ( ab )?
Quiero saber lo siguiente:
¿Cuántas personas por minuto puede manejar el sitio?
Por favor, guíeme a través de los comandos que debería ejecutar para resolver esto.
Intenté cada tutorial, y son confusos.
Cargar la prueba de su API usando solo ab no es suficiente. Sin embargo, creo que es una gran herramienta para darle una idea básica de cómo su sitio está funcionando.
Si desea usar el comando ab para probar múltiples puntos finales API, con datos diferentes, todos al mismo tiempo en segundo plano, debe usar el comando "nohup". Ejecuta cualquier comando incluso cuando cierra la terminal.
Escribí un script simple que automatiza todo el proceso, siéntete libre de usarlo: http://blog.ikvasnica.com/entry/load-test-multiple-api-endpoints-concurrently-use-this-simple-shell-script
La herramienta de referencia de apache es muy básica, y si bien le dará una idea sólida de algunos resultados, es una mala idea depender solo de ella si planea exponer su sitio a un estrés grave en la producción.
Una vez dicho esto, aquí están los parámetros más comunes y simples:
-c : ("Concurrencia"). Indica cuántos clientes (personas / usuarios) llegarán al sitio al mismo tiempo. Mientras ab ejecuta, habrá clientes que accedan al sitio. Esto es lo que realmente decide la cantidad de estrés que su sitio sufrirá durante el benchmark.
-n : Indica cuántas solicitudes se van a realizar. Esto solo decide la longitud del punto de referencia. Un valor alto -n con un valor -c que su servidor puede admitir es una buena idea para garantizar que las cosas no se rompan bajo un estrés sostenido: no es lo mismo soportar el estrés durante 5 segundos que durante 5 horas.
-k : Esto hace que los navegadores de funcionalidad "KeepAlive" lo hagan por naturaleza. No necesita pasar un valor para -k como "booleano" (es decir: indica que desea que su prueba use el encabezado Keep Alive desde HTTP y mantenga la conexión). Dado que los navegadores hacen esto y es probable que desee simular el estrés y el flujo que su sitio tendrá de los navegadores, se recomienda hacer un punto de referencia con esto.
El argumento final es simplemente el anfitrión. De forma predeterminada, se presionará http: // protocolo si no lo especifica.
ab -k -c 350 -n 20000 example.com/
Al emitir el comando anterior, accederá a http://example.com/ con 350 conexiones simultáneas hasta que se cumplan 20 mil solicitudes. Se hará usando el encabezado keep alive.
Después de que el proceso finalice las 20 mil solicitudes, recibirás comentarios sobre las estadísticas. Esto le indicará qué tan bien se desempeñó el sitio bajo el estrés que puso al usar los parámetros anteriores.
Para saber cuántas personas puede manejar el sitio al mismo tiempo, solo vea si los tiempos de respuesta (tiempos medios, mínimos y máximos de respuesta, solicitudes fallidas, etc.) son números que su sitio puede aceptar (diferentes sitios pueden desear velocidades diferentes). Puede ejecutar la herramienta con diferentes valores -c hasta que llegue al punto donde dice "Si lo aumento, comienza a recibir solicitudes fallidas y se rompe".
Según su sitio web, esperará una cantidad promedio de solicitudes por minuto. Esto varía mucho, no podrás simular esto con ab. Sin embargo, piénselo de esta manera: si su usuario promedio alcanzará 5 solicitudes por minuto y el tiempo promedio de respuesta que encuentre válido es de 2 segundos, eso significa que 10 de cada 1 usuario estará atendiendo solicitudes, lo que significa 1/6 del tiempo llegará al sitio. Esto también significa que si tiene 6 usuarios que acceden al sitio con ab simultáneamente, es probable que tenga 36 usuarios en simulación, aunque su nivel de concurrencia (-c) sea solo 6.
Esto depende del comportamiento que espera de los usuarios que utilizan el sitio, pero puede obtenerlo de "Espero que mi usuario acceda a X solicitudes por minuto y considero que un tiempo de respuesta promedio es válido si es de 2 segundos". Luego, simplemente modifique su nivel -c hasta que alcance 2 segundos de tiempo promedio de respuesta (pero asegúrese de que el tiempo máximo de respuesta y stddev aún sean válidos) y vea qué tan grande puede hacer -c.
Espero haber explicado esto claro :) Buena suerte
Pasos para configurar Apache Bench (AB) en Windows (IMO - Recommended).
Paso 1 - Instala Xampp.
Paso 2 - Abre CMD.
Paso 3: vaya al destino del banco Apache ( cd C:/xampp/apache/bin ) desde CMD
Paso 4 - Pegue el comando ( ab -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://localhost:yourport/ )
Paso 5 - Espera. Terminaste