una - ¿Cómo se supone que debo interpretar los resultados de la herramienta de evaluación comparativa de Apache?

evaluacion del desempeño

Question

De acuerdo, he buscado en todas partes y parece que no puedo encontrar un recurso detallado en línea sobre cómo interpretar los resultados de la herramienta de evaluación comparativa del servidor ab de Apache. He realizado varias pruebas con parámetros que consideré drásticamente diferentes, pero he visto resultados muy similares (¡me cuesta pensar que esto significa que mi sitio escala a la perfección!). Si hay un recurso detallado que alguien podría indicarme, sobre cómo entender los resultados de esta prueba, o si alguien tiene ganas de crear uno aquí, creo que sería muy útil para mí y para otros.

Answer 1

En la parte superior de la respuesta de Creuzerm. Aquí hay un enlace muy bueno con algo más de información

https://serverfault.com/questions/274252/apache-ab-please-explain-the-output

En cuanto a la diferencia entre líneas

Time per request:       7.303 [ms] (mean)
Time per request:       0.730 [ms] (mean, across all concurrent requests)

Answer 2

En una nota al margen, AB es de un solo subproceso (lo cual está bien para CPU antiguas de un solo núcleo como el 2001 Pentium 4).

Para probar una CPU de varios núcleos que aloja un servidor web (Nginx / Lighty usando varios procesos, Apache usando varios subprocesos), debería usar Weighttp (que es compatible con AB).

"Weighttp -t 6" ejecutará 6 hilos de cliente (por el contrario "AB -t 6" ejecutará una prueba de 6 segundos).

Obtendrá resultados mucho más relevantes utilizando varios subprocesos de cliente (tantos como el número de trabajadores del servidor web, que debe coincidir con la cantidad de Núcleos de CPU del recuadro del servidor).

Answer 3

Frustrante, ¿no? Estoy tratando de hacer lo mismo, ver cómo mi servidor dedicado recién provisto y configurado se compara con otros.

Lo que estoy haciendo es comparar mi servidor de producción actual (Dual core 4GB RAM) con el nuevo servidor (Quad core 8GB RAM).

Necesito ''jugar bien'' con mis comparaciones lado a lado, ya que el servidor de producción está en vivo y no quiero ''romper'' el servidor para mis usuarios.

Comparando el actual vs nuevo con el siguiente comando en una página php que simplemente llama a phpinfo (): ab -kc 20 -t 60

En mi servidor de producción actual, veo algo como lo siguiente, donde no pudo completar la tarea en la cantidad de tiempo dada:

Time taken for tests:   60.1234 seconds
Complete requests:  24538
Failed requests:    58
(Connect: 0, Length:    58, Exceptions: 0)
Requests per second:    408.96 [#/sec] (mean)
Time per request:   48.905 [ms] (mean)
Time per request:   2.445 [ms] (mean, across all concurrent requests)

VS lo siguiente en el nuevo servidor que completó todas las pruebas en la mitad de la cantidad de tiempo:

Time taken for tests:   29.838791 seconds
Complete requests:  50000
Failed requests:    11
(Connect: 0, Length:    11, Exceptions: 0)
Requests per second:    1675.67 [#/sec] (mean)
Time per request:   11.936 [ms] (mean)
Time per request:   0.597 [ms] (mean, across all concurrent requests)

Ahora bien, esta no es realmente una prueba "justa", ya que el servidor actual maneja 20 sitios web además de la prueba de referencia. Además, en realidad solo está probando apache y php.

Poniendo esta misma prueba en una de mis páginas principales más complejas, una que "parece" lenta en el servidor actual, veo lo siguiente: Servidor actual:

Time taken for tests:   60.14170 seconds
Complete requests:  510
Requests per second:    8.50 [#/sec] (mean)
Time per request:   2353.497 [ms] (mean)
Time per request:   117.675 [ms] (mean, across all concurrent requests)

Nuevo servidor:

Time taken for tests:   60.18651 seconds
Complete requests:  1974
Requests per second:    32.89 [#/sec] (mean)
Time per request:   608.092 [ms] (mean)
Time per request:   30.405 [ms] (mean, across all concurrent requests)

Esta prueba carga una página de Joomla CMS generada dinámicamente. Es un poco más una prueba del "mundo real". Una vez más, con el nuevo servidor no lidia con el tráfico del sitio actual, por lo que no es una comparación de manzanas a manzanas. No quiero probar mucho más o arriesgo la experiencia de mi usuario final en mis sitios.

Después de migrar los sitios al nuevo servidor, planeo volver a hacer las pruebas anteriores para poder ver qué efecto tiene el tráfico de mi sitio habitual en la evaluación comparativa. La producción de la misma máquina frente a los resultados de referencia inactivos.

Ahora, también estoy tratando de enfatizar el nuevo servidor y asegurarme de que reaccione bien. Ejecutando el comando ab -n 50000 -c 200 Estoy viendo el comando superior y viendo cuánta CPU y memoria se están usando, mientras que * f5 * ing la página en mi navegador para ver si obtengo algún error y también para tener una idea por cuánto tiempo le toma al servidor responder.

Mi primera prueba me dio:

Concurrency Level:  200
Time taken for tests:   692.160011 seconds
Complete requests:  50000
Failed requests:    30102
(Connect: 0, Length:    30102, Exceptions: 0)
Write errors:   0
Non-2xx responses:  30102
Total transferred:  456568770 bytes
HTML transferred:   442928962 bytes
Requests per second:    72.24 [#/sec] (mean)
Time per request:   2768.640 [ms] (mean)
Time per request:   13.843 [ms] (mean, across all concurrent requests)
Transfer rate:  644.17 [Kbytes/sec] received

Tenga en cuenta la muy alta tasa de solicitudes fallidas. Mi apache está configurado para un máximo de 250 solicitudes simultáneas, pero mi MySQL estaba en solo 175. MySQL fue el punto de falla aquí. No pudo procesar todas las solicitudes provenientes de apache. La carga de la página de mi navegador web me estaba dando una página de error de conexión MySQL en muchas actualizaciones de página.

Por lo tanto, aumenté MySQL a 300 solicitudes simultáneas (ya lo había hecho, pero había olvidado reiniciar MySQL, así que resultó ser una buena prueba; identifiqué un cambio necesario y accidentalmente hice una prueba empírica para validar el cambio). necesidad).

La siguiente ejecución me dio los siguientes resultados:

Concurrency Level:      200
Time taken for tests:   1399.999463 seconds
Complete requests:      50000
Failed requests:        5054
   (Connect: 0, Length: 5054, Exceptions: 0)
Write errors:           0
Non-2xx responses:      5054
Total transferred:      1016767290 bytes
HTML transferred:       995713274 bytes
Requests per second:    35.71 [#/sec] (mean)
Time per request:       5599.998 [ms] (mean)
Time per request:       28.000 [ms] (mean, across all concurrent requests)
Transfer rate:          709.24 [Kbytes/sec] received

Esto tomó más del doble de tiempo, pero la tasa de solicitudes fallidas fue mucho menor. Básicamente, el servidor ahora está configurado para poder manejar al menos 200 vistas de página simultáneas de una de las páginas de inicio de mi sitio, pero tomará 5 segundos para que una página las publique. No es genial, pero es mucho mejor que los errores de MySQL que recibía anteriormente.

Durante todo esto, el uso de la CPU de mi servidor está vinculado al 100% con el ''promedio de carga'' flotando hacia arriba de 180. MySQL está usando alrededor del 8-9% de la CPU y no está usando mucha de la RAM que le he asignado , ya que solo estoy martillando repetidamente la misma página, por lo que solo se trata de una única base de datos. 400 MB de los 4 GB + está configurado para crecer. arriba muestra los búferes y el uso de la memoria en caché en aproximadamente el 50% de la RAM total disponible. Así que mientras estoy cargando la máquina con esta prueba, no se está acercando al punto sobrecargado. Bajo el uso de una base de datos del mundo real, MySQL debería tomar gran parte de la memoria que he asignado, por lo que el servidor debería estar bastante cerca de la carga completa en ese momento.

Mi siguiente prueba fue probar apache a ''carga completa'' de 250 conexiones ab -n 50000 -c 250

Concurrency Level:      250
Time taken for tests:   1442.515514 seconds
Complete requests:      50000
Failed requests:        3509
   (Connect: 0, Length: 3509, Exceptions: 0)
Write errors:           0
Non-2xx responses:      3509
Total transferred:      1051321215 bytes
HTML transferred:       1029809879 bytes
Requests per second:    34.66 [#/sec] (mean)
Time per request:       7212.577 [ms] (mean)
Time per request:       28.850 [ms] (mean, across all concurrent requests)
Transfer rate:          711.73 [Kbytes/sec] received

Esto muestra resultados similares a la prueba de conexión 200 con el límite de conexión MySQL adecuado. Esto es bueno para mí, creo. No me gustan los 7 segundos para devolver una página, pero creo que puedo mejorar eso en el nivel de Joomla al habilitar el almacenamiento en memoria caché en Joomla con APC o Memcache que ambos están instalados pero aún no utilizados por Joomla.

Tratando de presionar mi suerte, pensé que probaría 300 conexiones simultáneas. ab -n 50000 -c 300 El navegador muestra una larga espera para una carga rápida de la página. De lo contrario, no hay mucho cambio en los resultados.

Concurrency Level:      300
Time taken for tests:   1478.35890 seconds
Complete requests:      50000
Failed requests:        2266
   (Connect: 0, Length: 2266, Exceptions: 0)
Write errors:           0
Non-2xx responses:      2266
Total transferred:      1079120910 bytes
HTML transferred:       1057241646 bytes
Requests per second:    33.83 [#/sec] (mean)
Time per request:       8868.215 [ms] (mean)
Time per request:       29.561 [ms] (mean, across all concurrent requests)
Transfer rate:          712.99 [Kbytes/sec] received

No sé si mi interpretación de estos resultados es "correcta" o si me falta algo valioso, pero con la falta de instrucción que pude encontrar, esto es lo que se me ocurrió.

Acabo de utilizar los resultados para asegurarme de obtener una buena tasa de respuesta, la falta de una tasa de respuesta perfecta me preocupa, pero no sé cómo ver o reproducir los fallos de una manera que pueda inspeccionarlos.

El tiempo lento por solicitud también me preocupa, pero creo que puedo abordar mucho de eso en la capa de aplicación.

Estoy seguro de que, si bien el servidor se ralentizaría, podría manejar una situación de carga pesada.

Mirar otras herramientas de ajuste del rendimiento como MonYog después de estas pruebas comparativas también me ha demostrado que mis configuraciones actuales son "lo suficientemente buenas".

Ojalá hubiera un lugar donde las personas hayan publicado los resultados de las pruebas que puedo reproducir con una descripción de hardware y configuraciones de software, así sé si soy ''competitivo'' o si todavía tengo mucho trabajo por hacer para utilizar mejor mi equipo. Por lo tanto, ¿por qué estoy publicando mis resultados?

Answer 4

Tenga en cuenta que para la línea de "solicitudes fallidas", una solicitud fallida se determina comparando la duración de las solicitudes subsiguientes entre sí. ¡Para el sitio web dinámico, esto no tiene que significar que la solicitud falló en absoluto! Así que no te preocupes por la línea de solicitud fallida.

Ver también: http://www.celebrazio.net/tech/unix/apache_bench.html

Answer 5

Time per request:       7.303 [ms] (mean)
Time per request:       0.730 [ms] (mean, across all concurrent requests)

el primero está relacionado con el tiempo promedio de solicitud por usuarios concurrentes, por lo que si está realizando la prueba de 1000 solicitudes y 200 usuarios concurrentes, la primera será el tiempo promedio para cada solicitud 200. el segundo está relacionado con el tiempo de solicitud general, que es el tiempo promedio sobre las 1000 solicitudes completas