Al configurar el proxy HA, ¿cómo decide qué valores asignar a los tiempos de espera? He leído media docena de muestras en varios blogs, y todos usan diferentes tiempos de espera y nadie discute por qué.

HAProxy parece específicamente preocupado por el cliente, la conexión y el servidor, sobre lo cual HAPRoxy lanza una advertencia si se deja completamente sin configurar:

While not properly invalid, you will certainly encounter various problems
with such a configuration. To fix this, please ensure that all following
timeouts are set to a non-zero value: 'client', 'connect', 'server'.

La documentación no es útil a este respecto: sugiere "un poco por encima de los múltiplos de 3 segundos", pero no por qué elegiría un múltiplo de 1 frente a 100 o 42.

El RPM que estoy usando (repositorio de Amazon Linux) establece estos valores predeterminados:

timeout connect         10s
timeout client          1m
timeout server          1m

Dos de los cuales son múltiplos exactos de 3 segundos, violando el único consejo oficial que he visto.

Si no tiene un consejo de ajuste específico, tal vez una pregunta más fácil es: ¿qué debo esperar que salga mal con tiempos de espera realmente cortos o muy largos?

El TCP RTO (tiempo de espera de recepción) comienza a los tres segundos. ( RFC 1122 ) Si un paquete transmitido no ha recibido un acuse de recibo en ese momento, entonces se supone que se pierde y se retransmite. Esto es casi seguro a lo que se refiere el autor. (Tenga en cuenta que el RTO se ajusta o desactiva dinámicamente mediante varios algoritmos , fuera del alcance de esta pregunta).

Tenga en cuenta que esto realmente solo se aplica a las conexiones entre su servidor front-end y los clientes (es decir, usuarios web). En escenarios normales, las conexiones entre HAProxy y sus servidores back-end deben estar en una LAN y debe usar tiempos de espera mucho más cortos, para que los backends que funcionen mal se retiren del servicio antes.

En cuanto a sus usuarios web, algunos de ellos pueden estar en conexiones de latencia muy alta, como el satélite, y pueden experimentar retransmisiones más altas de lo normal debido a esto. El RTT en una conexión donde se usa un satélite puede exceder los 2000 ms, incluso si todo está bien.

Con todo esto en mente, generalmente querrás tiempos de espera muy cortos timeout connecty muy largos timeout client.

Para timeout server, esto depende de su aplicación web. Al configurar el tiempo de espera, considere la complejidad de la aplicación web que se está sirviendo y cuánto tiempo puede tomar en el peor de los casos procesar una solicitud compleja. En caso de duda, aumente el valor.

Prefacio

He estado ajustando HAProxy por un tiempo y he realizado muchas pruebas de rendimiento. Desde 100 solicitudes HTTP / s hasta 50 000 solicitudes HTTP / s.

El primer consejo es habilitar la página de estadísticas en HAProxy . NECESITA monitoreo, sin excepción. También necesitará un ajuste fino si tiene la intención de superar las 10,000 solicitudes / s.

Los tiempos de espera son una bestia confusa porque tienen una gran variedad de valores posibles, la mayoría de ellos sin diferencias observables. Todavía tengo que ver que algo falle debido a un número 5% menor o 5% mayor. 10000 vs 11000 milisegundos, ¿a quién le importa? Probablemente no sea tu sistema.

Configuración

En buena conciencia, no puedo dar un par de números como "los mejores tiempos de espera para todos".

Lo que sí puedo decir son los tiempos de espera MÁS agresivos que siempre son aceptables para el equilibrio de carga HTTP (S). Si encuentra más bajo que estos, es hora de reconfigurar su equilibrador de carga.

timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000

cliente de tiempo de espera:

El tiempo de inactividad se aplica cuando se espera que el cliente reconozca o envíe datos. En el modo HTTP, este tiempo de espera es particularmente importante a considerar durante la primera fase, cuando el cliente envía la solicitud y durante la respuesta mientras lee los datos enviados por el servidor.

Leer : este es el tiempo máximo para recibir encabezados de solicitud HTTP del cliente.

3G / 4G / 56k / satélite puede ser lento a veces. Aún así, deberían poder enviar encabezados HTTP en unos segundos, NO 30.

Si alguien tiene una conexión tan mala que necesita más de 30 segundos para solicitar una página (luego más de 10 * 30 segundos para solicitar las 10 imágenes incrustadas / CSS / JS), creo que es aceptable rechazarlo.

servidor de tiempo de espera:

El tiempo de inactividad se aplica cuando se espera que el servidor reconozca o envíe datos. En el modo HTTP, este tiempo de espera es particularmente importante a considerar durante la primera fase de la respuesta del servidor, cuando tiene que enviar los encabezados, ya que representa directamente el tiempo de procesamiento del servidor para la solicitud. Para averiguar qué valor poner allí, a menudo es bueno comenzar con lo que se considerarían tiempos de respuesta inaceptables, luego verifique los registros para observar la distribución del tiempo de respuesta y ajuste el valor en consecuencia.

Leer : este es el tiempo máximo para recibir encabezados de respuesta HTTP del servidor (después de que recibió la solicitud completa del cliente). Básicamente, este es el tiempo de procesamiento de sus servidores, antes de que comience a enviar la respuesta.

Si su servidor es tan lento que requiere más de 30 segundos para comenzar a dar una respuesta, entonces creo que es aceptable considerarlo muerto.

Caso especial : algunos servicios RAROS que realizan un procesamiento muy pesado pueden tardar un minuto o más en responder. Es posible que sea necesario aumentar mucho este tiempo de espera para este uso específico. (Nota: es probable que este sea un caso de mal diseño, use una comunicación de estilo asíncrono o no use HTTP en absoluto).

tiempo de espera de conexión:

Establezca el tiempo máximo de espera para que un intento de conexión a un servidor tenga éxito.

Leer : el tiempo máximo que un servidor tiene para aceptar una conexión TCP.

Los servidores están en la misma LAN que HAProxy, por lo que debería ser rápido. Déle al menos 5 segundos porque ese es el tiempo que puede tomar cuando ocurre algo inesperado (un paquete TCP perdido para retransmitir, un servidor que bifurca un nuevo proceso para tomar las nuevas solicitudes, un aumento en el tráfico).

Caso especial : cuando los servidores están en una LAN diferente o sobre un enlace poco confiable. Es posible que sea necesario aumentar mucho este tiempo de espera. (Nota: es probable que esto sea un caso de mala arquitectura).

verificación de tiempo de espera:

Establezca un tiempo de espera de verificación adicional, pero solo después de que se haya establecido una conexión.

Establezca un tiempo de espera de verificación adicional, pero solo después de que ya se haya establecido una conexión Si ha establecido, haproxy usa min ("timeout connect", "inter") como tiempo de espera de conexión para la verificación y "timeout check" como tiempo de espera de lectura adicional. El "min" se utiliza para que las personas que se ejecutan con un "tiempo de espera excedido" muy largo (por ejemplo, aquellos que lo necesitaban debido a la cola o al tarpit) no reduzcan la velocidad de sus controles. (Tenga en cuenta también que no hay una razón válida para tener tiempos de espera de conexión tan largos, porque "cola de tiempo de espera" y "tarpit de tiempo de espera" siempre se pueden usar para evitar eso).

Leer : Al realizar una comprobación de estado, el servidor timeout connectdebe aceptar la conexión y luego timeout checkdar la respuesta.

Todos los servidores DEBEN tener una comprobación de estado HTTP (S) configurada. Esa es la única forma para que el equilibrador de carga sepa si hay un servidor disponible. El chequeo de salud es una /isalivepágina simple que siempre responde OK.

Dé a este tiempo de espera al menos 5 segundos porque es el tiempo que puede tomar cuando sucede algo inesperado (un paquete TCP perdido para retransmitir, un servidor que bifurca un nuevo proceso para tomar las nuevas solicitudes, un pico en el tráfico).

Historia de guerra : Mucha gente cree erróneamente que el servidor siempre puede responder a esta página simple en 3 ms. Establecieron un tiempo de espera agresivo (<2000 ms) con conmutación por error agresiva (2 comprobaciones fallidas = servidor muerto). He visto sitios web enteros cayendo debido a eso. Por lo general, hay un ligero aumento en el tráfico, los servidores de fondo se vuelven más lentos, los controles de salud se retrasan ... hasta que de repente se agotan todos juntos, HAProxy cree que TODOS los servidores murieron de inmediato y todo el sitio se cae.