Asumí incorrectamente que mi prueba AB interna significa que mi servidor puede manejar 1k concurrencia @ 3k visitas por segundo.

Mi teoría en este momento es que la red es el cuello de botella. El servidor no puede enviar suficientes datos lo suficientemente rápido.

Las pruebas externas de blitz.io con una concurrencia de 1k muestran que mis hits / s tienen un límite de 180, y las páginas tardan más y más en responder, ya que el servidor solo puede devolver 180 por segundo.

He servido un archivo en blanco de nginx y lo he guardado: escala 1: 1 con concurrencia.

Ahora para descartar cuellos de botella de IO / memcached (nginx normalmente se extrae de memcached), presento una versión estática de la página en caché del sistema de archivos.

Los resultados son muy similares a mi prueba original; Tengo un límite de alrededor de 180 RPS.

Dividir la página HTML por la mitad me da el doble de RPS, por lo que definitivamente está limitado por el tamaño de la página.

Si internamente ApacheBench desde el servidor local, obtengo resultados consistentes de alrededor de 4k RPS tanto en la página completa como en la media página, a altas tasas de transferencia. Velocidad de transferencia: 62586.14 [Kbytes / seg] recibidos

Si AB de un servidor externo, obtengo alrededor de 180RPS, lo mismo que los resultados de blitz.io.

¿Cómo sé que no es un estrangulamiento intencional?

Si comparo con varios servidores externos, todos los resultados se vuelven pobres, lo que me lleva a creer que el problema está en el tráfico saliente de MIS servidores, no en un problema de velocidad de descarga con mis servidores de evaluación comparativa / blitz.io.

Así que vuelvo a la conclusión de que mi servidor no puede enviar datos lo suficientemente rápido.

Estoy en lo cierto? ¿Hay otras formas de interpretar estos datos? ¿La solución / optimización es configurar múltiples servidores + balanceo de carga que pueden servir 180 golpes por segundo?

Soy bastante nuevo en la optimización del servidor, así que agradecería cualquier confirmación que interprete estos datos.

Tráfico saliente

Aquí hay más información sobre el ancho de banda saliente: el gráfico de red muestra una salida máxima de 16 Mb / s: 16 megabits por segundo. No parece mucho en absoluto.

Debido a una sugerencia sobre el estrangulamiento, investigué esto y descubrí que linode tiene un límite de 50mbps (que aparentemente ni siquiera estoy cerca de golpear). Lo hice subir a 100mbps.

Dado que linode limita mi tráfico, y ni siquiera lo estoy alcanzando, ¿significa esto que mi servidor debería ser capaz de generar hasta 100 Mbps pero está limitado por algún otro cuello de botella interno? Simplemente no entiendo cómo funcionan las redes a esta gran escala; ¿Pueden literalmente enviar datos tan rápido como pueden leer desde el HDD? ¿La tubería de red es tan grande?

En conclusión

1: Basado en lo anterior, creo que definitivamente puedo aumentar mi 180RPS agregando un equilibrador de carga nginx en la parte superior de una configuración de servidor multi nginx a exactamente 180RPS por servidor detrás del LB.

2: Si linode tiene un límite de 50 / 100mbit que no estoy alcanzando en absoluto, debe haber algo que pueda hacer para alcanzar ese límite con la configuración de mi único servidor. Si puedo leer / transmitir datos lo suficientemente rápido localmente, y Linode incluso se molesta en tener un límite de 50mbit / 100mbit, debe haber un cuello de botella interno que no me permite alcanzar esos límites que no estoy seguro de cómo detectar. ¿Correcto?

Me doy cuenta de que la pregunta es enorme y vaga ahora, pero no estoy seguro de cómo condensarla. Cualquier contribución es apreciada en cualquier conclusión que haya hecho.

El problema era que suponía que los picos de gráficos de linode.com eran picos verdaderos. Resulta que el gráfico usa puntos de datos promedio de 5 minutos, por lo tanto, mi pico parecía ser de 24 mbits cuando, de hecho, estaba alcanzando el límite de 50 mbits.

Ahora que lo han elevado a 100 Mbits, mis puntos de referencia subieron inmediatamente al nuevo límite de tráfico saliente.

¡Ojalá me hubiera dado cuenta antes! Gran parte de mi razonamiento dependía de la idea de que no estaba alcanzando un límite de tráfico saliente debido a ese gráfico.

Ahora, alcanzo un máximo de 370 solicitudes por segundo, que está justo por debajo de los 100 Mbps, momento en el que empiezo a recibir una "acumulación" de solicitudes y los tiempos de respuesta comienzan a aumentar.

Ahora puedo aumentar la concurrencia máxima reduciendo la página; con gzip habilitado obtengo 600RPS.

Todavía me encuentro con problemas cuando de repente alcanzo un pico y la acumulación de solicitudes pendientes (limitadas por el ancho de banda) comienza a acumularse, pero eso parece una pregunta diferente.

Ha sido una gran lección sobre optimización / lectura de estos datos / reducción de los posibles problemas. ¡Muchas gracias por tu aporte!

Un poco tarde ahora que lo descubriste ... pero tal vez deberías considerar leer el blog ServerFault de vez en cuando.

Estoy pensando en particular en esta publicación , donde discuten por qué tener un intervalo de sondeo de un segundo no lo corta de vez en cuando, en relación con un problema muy similar al que tenía ...

Descubrimos que descartábamos paquetes con bastante frecuencia en interfaces de 1 Gbit / s a ​​velocidades de solo 10-30 MBit / s, lo que perjudica nuestro rendimiento. Esto se debe a que esa velocidad de 10-30 MBit / s es realmente el número de bits transferidos por 5 minutos convertidos a una velocidad de un segundo. Cuando profundizamos más con Wireshark y utilizamos gráficos de E / S de un milisegundo, vimos que frecuentemente explotábamos la velocidad de 1 Mbit por milisegundo de las llamadas interfaces de 1 Gbit / s.

Claro que me hizo pensar. Y sé que sé que estoy sacando eso de las otras SA en mi tienda la primera vez que tengo, y se verá perversamente brillante y perceptivo cuando nos encontremos con este problema.

Quién sabe, incluso puedo dejar que algunos de ellos en el secreto. :)

Puede estar limitado por la red, pero no necesariamente es simplemente una cuestión de ancho de banda. La latencia de su unidad de prueba remota tendrá un efecto en la cantidad de conexiones pendientes en un momento dado (esperar 50 ms para los reconocimientos es muy diferente a .5 ms localmente), así como en la negociación y estabilización del tamaño de las ventanas a medida que avanza la conexión. También es probable que esté expuesto a una cierta cantidad de pérdida de paquetes, ya sea en función de la congestión o como el mecanismo de limitación de ancho de banda por parte de su operador (o aquellos en sentido ascendente).

Sugeriría eliminar tanto como sea posible de la ecuación para dibujar una línea de base sensata. Mida el ancho de banda máximo, la latencia y la pérdida de paquetes de su servidor en algunos puntos de Internet en general. Por improbable que pueda parecer, intente buscar "Prueba de tráfico Voip" o similar. Varios proveedores de servicios VOIP tienen aplicaciones que pueden medir este tipo de patrones (bidireccionalmente) con un alto grado de precisión. Una vez que tenga algunos datos empíricos válidos en cuanto a la velocidad útil real de su enlace, sus resultados bien pueden ser validados.

Además de las pruebas de ancho de banda, también podría ser útil observar una captura de paquetes del tráfico web por debajo del par para buscar un número excesivo de retransmisiones, así como medir el tiempo aparente que su servidor tarda en responder a las solicitudes (..si esto el valor está aumentando sustancialmente en función del número de conexiones, esta es una gran pista).