haproxy: retener las sesiones existentes bajo alta carga, servir '503' a los recién llegados

Tratando de hacer lo que dice en el título: retener las sesiones existentes con mucha carga y enviar mensajes 503 a los visitantes recién llegados.

Problema: funciona, pero las sesiones no duran más de 90 segundos.

Los resultados actuales me hacen preguntarme si hay una configuración de tiempo de espera que me falta.

Propósito

Estoy tratando de obtener haproxy para:

• envíe solicitudes de nuevas sesiones al back-end-001 cuando el número total de sesiones en la interfaz esté por debajo de cierto umbral.
• Servir un error 503 a nuevas sesiones cuando el número total de sesiones en la interfaz está por encima de ese umbral
• permitir solicitudes para sesiones existentes incluso si el número de sesiones excede el umbral

De esta manera, los visitantes que están en el medio de completar un formulario de varios pasos no se sorprenderán con un error 503, y se puede decir a los nuevos visitantes que "vuelvan más tarde porque estamos realmente ocupados en este momento".

Preparar

La configuración es la siguiente:

            {visitors}
                ↓ 
            [haproxy]
                ↓ 
[rails app on unicorn served by nginx]   (right now just one 
                                            backend: 'backend-001')

enfoque actual

Para lograr lo anterior, estoy usando la configuración a continuación.

Este es para pruebas, con un límite muy bajo (10 conexiones en el front-end (fe_conn gt 10)), para facilitar las pruebas.

Para poner el servidor bajo carga, estoy usando httperf de la siguiente manera:

httperf --hog --server staging.machine.tld --uri / do_some_things --wsess = 500,10,30 --rate 2

global
    daemon
    maxconn 10000

defaults
    mode        http
    timeout connect 6s
    timeout client  60s
    timeout server  60s
    balance roundrobin
    option http-server-close

frontend http-in
    bind [PUBLIC_IP]:80

    default_backend backend-001

    acl too_many fe_conn gt 10
    use_backend b_too_many if too_many

backend backend-001
    fullconn 10
    appsession _session_id len 128 timeout 7200s

    cookie SERVERID insert maxidle 7200s
    server Server1 127.0.10.1:80 cookie backend-001 check

backend b_too_many
    errorfile 503 /var/www/50x.html

problema

Como se mencionó anteriormente, el problema es: casi funciona, pero las sesiones no duran más de 90 segundos.

Si sigue haciendo clic, puede mantener su sesión incluso cuando hay 10 sesiones ocupadas.

Intentar abrir una página en el servidor con una instancia de navegador diferente le da el error 503.

Entonces, parece que ya casi estoy allí. ¿Alguien tiene una idea de lo que podría estar causando los cortos tiempos de sesión?

Y particularmente cómo puedo solucionarlo :)

(editar: eliminó 'weight 1 maxconn 10' de la línea 'server', no es relevante y podría confundir) (edite la 2da: '10 sesiones corregidas en el front-end 'a '10 conexiones en el front-end')

Desafortunadamente, pareces tener conexiones completamente confusas con sesiones de nivel de aplicación. Un usuario que visita el sitio puede tener una cookie que le hace pensar que posee una conexión, aunque no es necesariamente el caso. Podría abrir tantas conexiones como sea necesario para buscar objetos y navegar por las páginas.

Los 90 segundos que está observando seguramente es el tiempo de espera del navegador para conexiones inactivas.

Es posible lograr lo que desea, pero es un poco más complejo que eso, ya que también debe considerar la presencia de la cookie de persistencia en la solicitud para determinar si el visitante es nuevo o no.

Además, en general, es más eficiente confiar en el recuento promedio de conexiones por servidor que en el recuento de conexiones frontend. La razón es que cuando un servidor muere, necesita reajustar este número. La forma más eficiente de hacerlo es configurar un valor de maxconn del servidor para habilitar las colas y usar avg_queue para que el límite se aplique al número promedio de solicitudes en cola en los servidores. Esto le permite manejar correctamente los visitantes conocidos mientras mueve suavemente a los nuevos usuarios a otro backend cuando la carga aumenta debido a los visitantes existentes.