La herramienta de referencia de Apache es muy básica y, si bien le dará una idea sólida de cierto rendimiento, es una mala idea depender solo de ella si planea exponer su sitio a un estrés grave en la producción.
Dicho esto, aquí están los parámetros más comunes y más simples:
-c
: ("Concurrencia"). Indica cuántos clientes (personas / usuarios) estarán visitando el sitio al mismo tiempo. Mientras se ab
ejecuta, habrá -c
clientes visitando el sitio. Esto es lo que realmente decide la cantidad de estrés que sufrirá su sitio durante el punto de referencia.
-n
: Indica cuántas solicitudes se realizarán. Esto simplemente decide la duración del punto de referencia. Un buen -n
valor con un -c
valor que su servidor pueda soportar es una buena idea para asegurarse de 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 la funcionalidad de los navegadores "KeepAlive" por naturaleza. No necesita pasar un valor -k
ya que es "booleano" (lo que significa que indica que desea que su prueba use el encabezado Keep Alive de 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 que haga un punto de referencia con esto.
El argumento final es simplemente el anfitrión. Por defecto, golpeará el protocolo http: // 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 realizará utilizando el encabezado keep alive.
Después de que el proceso finalice las 20 mil solicitudes, recibirá comentarios sobre las estadísticas. Esto le dirá qué tan bien se desempeñó el sitio bajo el estrés que lo puso al usar los parámetros anteriores.
Para averiguar cuántas personas puede manejar el sitio al mismo tiempo, solo vea si los tiempos de respuesta (medios, tiempos de respuesta mínimos y máximos, 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 lugar donde dice "Si lo aumento, comienza a recibir solicitudes fallidas y se rompe".
Dependiendo de su sitio web, esperará un número promedio de solicitudes por minuto. Esto varía tanto que no podrá simular esto con ab. Sin embargo, piénselo de esta manera: si su usuario promedio recibirá 5 solicitudes por minuto y el tiempo de respuesta promedio que encuentra válido es de 2 segundos, eso significa que 10 segundos de un minuto 1 usuario estará en solicitudes, lo que significa solo 1/6 de las veces 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 la simulación, a pesar de que su nivel de concurrencia (-c) es solo 6.
Esto depende del comportamiento que espera de sus usuarios que usan el sitio, pero puede obtenerlo de "Espero que mi usuario llegue a X solicitudes por minuto y considero un tiempo de respuesta promedio válido si es de 2 segundos". Luego, simplemente modifique su nivel -c hasta alcanzar los 2 segundos de tiempo de respuesta promedio (pero asegúrese de que el tiempo de respuesta máximo y stddev sigan siendo válidos) y vea qué tan grande puede hacer -c.
Espero haber explicado esto claro :) Buena suerte
-l
opción si la página tiene contenido dinámico, de esa manera no obtendrá un montón de solicitudes fallidas debido a que la longitud del contenido es diferente entre las solicitudes.La prueba más simple que puede hacer es realizar 1000 solicitudes, 10 a la vez (que simula aproximadamente 10 usuarios concurrentes que obtienen 100 páginas cada uno, a lo largo de la prueba).
-n 1000
es la cantidad de solicitudes a realizar.-c 10
le dice a AB que haga 10 solicitudes a la vez, en lugar de 1 solicitud a la vez, para simular mejor los visitantes concurrentes (frente a los visitantes secuenciales).-k
envía elKeepAlive
encabezado, que le pide al servidor web que no apague la conexión después de realizar cada solicitud, sino que en cambio la reutilice.También envío el encabezado adicional
Accept-Encoding: gzip, deflate
porque mod_deflate casi siempre se usa para comprimir la salida de texto / html 25% -75%, cuyos efectos no deben descartarse debido a su impacto en el rendimiento general del servidor web (es decir, puede transferir 2 veces los datos en la misma cantidad de tiempo, etc.Resultados:
Para la interpretación más simple, ignore todo PERO esta línea:
Multiplique eso por 60 y tendrá sus solicitudes por minuto.
Para obtener resultados del mundo real, querrá probar Wordpress en lugar de algún archivo HTML estático o index.php porque necesita 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 nueva instalación de Wordpress en el mismo sistema y entorno WAMP (estoy usando WampDeveloper, pero también hay Xampp, WampServer y otros) ...
¡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 una carga mayor (por ejemplo, aumentar
-n
y-c
tiende a fallar Apache), que puedes leer aquí:Prueba de carga Apache con AB (Apache Bench)
fuente
Pasos para configurar Apache Bench (AB) en Windows (IMO - Recomendado).
Paso 1 - Instala Xampp.
Paso 2: abre CMD.
Paso 3: vaya al destino de banco apache (
cd C:\xampp\apache\bin
) desde CMDPaso 4: pegue el comando (
ab -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://localhost:yourport/
)Paso 5: espere. Terminaste
fuente
También tenía curiosidad por saber si puedo medir la velocidad de mi script con apache abs o un script de medida de construcción / destrucción de php o una extensión de php.
los dos últimos me han fallado: son aproximados. después de lo cual pensé en probar "ab" y "abs".
¡el comando "ab -k -c 350 -n 20000 example.com/" es hermoso porque todo es más fácil!
pero ¿alguien pensó en "localhost" en algún servidor apache, por ejemplo www.apachefriends.org?
debes crear una carpeta como "bench" en la raíz donde tienes 2 archivos: prueba "bench.php" y referencia "void.php".
y luego: ¡referencia!
bench.php
void.php
en su escritorio, debe usar un archivo .bat (en Windows) como este:
bench.bat
Ahora, si prestas mucha atención ...
¡El script vacío no produce cero resultados! Así que la conclusión es: ¡a partir del segundo resultado, el primer resultado debe reducirse!
aquí tengo:
90-17 = 73 el resultado que espero!
fuente
La prueba de carga de su API utilizando solo ab no es suficiente. Sin embargo, creo que es una gran herramienta para darle una idea básica de cómo funciona su sitio.
Si desea utilizar el comando ab para probar varios puntos finales de 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éntase libre de usarlo: http://blog.ikvasnica.com/entry/load-test-multiple-api-endpoints-concurrently-use-this-simple-shell-script
fuente