Determinar una medida realista de solicitudes por segundo para un servidor web

15

Estoy configurando una pila nginx y optimizando la configuración antes de lanzarla. Al ejecutar ab para probar la máquina, me decepcionó ver que las cosas superan las 150 solicitudes por segundo con un número significativo de solicitudes que tardan> 1 segundo en regresar. Curiosamente, la máquina en sí ni siquiera respiraba con dificultad.

Finalmente pensé hacer ping a la caja y vi tiempos de ping alrededor de 100-125 ms. (La máquina, para mi sorpresa, está en todo el país). Entonces, parece que la latencia de la red está dominando mis pruebas. Al ejecutar las mismas pruebas desde una máquina en la misma red que el servidor (ping veces <1 ms) y veo> 5000 solicitudes por segundo, lo que está más en línea con lo que esperaba de la máquina.

Pero esto me hizo pensar: ¿cómo puedo determinar e informar una medida "realista" de solicitudes por segundo para un servidor web? Siempre ve reclamos sobre el rendimiento, pero ¿no debería tenerse en cuenta la latencia de la red? Claro que puedo atender 5000 solicitudes por segundo a una máquina al lado del servidor, pero no a una máquina en todo el país. Si tengo muchas conexiones lentas, eventualmente afectarán el rendimiento de mi servidor, ¿verdad? ¿O estoy pensando en todo esto mal?

Perdóname si esto es ingeniería de redes 101 cosas. Soy desarrollador de oficio.

Actualización: editado para mayor claridad.

— Don
fuente

abtiene una opción de concurrencia ¿A qué lo pusiste? Además, si está probando desde una conexión ADSL doméstica, es probable que la prueba esté dominada por su ancho de banda y no probará nada en el servidor.

— Ladadadada

Estoy familiarizado con la opción de concurrencia de ab y probé una amplia gama de valores para descubrir los límites del cuadro. Como escribí anteriormente, entiendo que mis pruebas iniciales estaban dominadas por la red y no reflejaban la capacidad del servidor. Pero mi pregunta sigue en pie: ¿desde dónde realizan la mayoría de las personas sus pruebas para obtener métricas realistas? Las pruebas se ejecutan desde un cuadro en la misma red que el servidor (eliminando efectivamente cualquier latencia de red de la ecuación) arrojan grandes números, pero no parecen números "justos" ya que los usuarios reales vendrán desde fuera de la red.

— Don

De hecho, las pruebas realizadas desde la misma red pueden ser más "justas" ya que esencialmente ignoran la red. Es probable que todos sus usuarios estén en redes diferentes, por lo que el ancho de banda agregado de todas esas redes debería exceder fácilmente el ancho de banda disponible de su servidor. Considerando a todos los usuarios juntos, el cuello de botella es, por lo tanto, las capacidades del servidor, mientras que considerando a un usuario individual, el cuello de botella puede ser el ancho de banda de ese único usuario. (La prueba ideal, tal vez, se ejecutaría desde múltiples ubicaciones remotas para simular mejor las circunstancias reales, aunque, la mayoría de los casos no deberían necesitar eso).

— cyberx86

"Considerando a todos los usuarios juntos, el cuello de botella es, por lo tanto, las capacidades del servidor", eso tiene sentido y parece ser la forma correcta de pensarlo. Supongo que el servidor podría estar sentado detrás de equipos de red deficientes, limitando su tasa de respuesta al mundo exterior, pero ese no es realmente el problema del servidor y debe abordarse por separado. Supongo que algo como Pingdom podría usarse para ejecutar la prueba ideal.

— Don

3

Si le importa el rendimiento de su servidor cuando se accede desde algún lugar del mundo, pídale a un amigo en algún lugar del mundo (debe tener un buen ancho de banda) que instale sproxy + siege en su caja de Linux. Solo descarga, configura, crea. Estas herramientas son pequeñas, se compilan en segundos.

Primero, comience sproxyen la caja de Linux. Por defecto, se ejecutará en el puerto 9001 en localhost (127.0.0.1). Si desea acceder desde afuera, simplemente pásele la dirección IP de salida como parámetro.
Ahora conéctese a sproxy configurando su navegador para usar esta ip y puerto como proxy para HTTP. Todo lo que hagas a partir de ahora es grabado por sproxy y puede reproducirse más tarde. Ahora navegue por su sitio, haga cosas que harían sus clientes e intente hacer cosas "caras" que utilicen su servidor.
Cuando termine, finalice sproxy presionando CTRL ^ C. Grabó sus acciones a $HOME/urls.txt. Mueva el archivo a donde reside el asedio. Para comenzar las pruebas de estrés, corre siege -f urls.txt -d NUM -c NUM. dsignifica retraso entre solicitudes, al hacer pruebas de rendimiento, use 1 (segundo).crepresenta el número de usuarios simultáneos simulados. Elija a voluntad, pero comience bajo. Siege le mostrará la cantidad de transacciones por segundo, tasa de error, cuánto tiempo demoraron las solicitudes promedio, etc. Es una herramienta poderosa y fácil de usar.
Si necesita más información sobre los parámetros (hay muchos), comprobar el estado de sitio manual de un el manual de sProxy

Para obtener resultados más realistas, permita que muchas personas prueben su servidor de varios países a la vez y que le envíen las estadísticas.

— SebiF
fuente

2

La medida realista de solicitudes / seg. Debe tomarse de los registros de acceso. En mi opinión, la latencia de la solicitud no tiene nada que ver con la carga del servidor, ya que el servidor procesa todas las solicitudes a la misma velocidad independientemente de su origen.

— ejaenv
fuente

1

Considere usar servicios como Soasta Cloudtest . Con él, puede obtener informes bastante detallados sobre sus pruebas y puede ejecutar pruebas de rendimiento de varios proveedores de nube pública / virtualización. Puede configurar qué tan duro y durante cuánto tiempo desea martillar sus servidores. También tienen una versión " lite " gratuita para que pueda ver lo que puede hacer antes de comprometer dinero.

— Mxx
fuente