Diferencia entre maxconn y servidor global maxconn HAProxy

Question

Tengo una pregunta acerca de mi config haproxy:

#--------------------------------------------------------------------- 
# Global settings 
#--------------------------------------------------------------------- 
global 
    log   127.0.0.1 syslog emerg 
    maxconn  4000 
    quiet 
    user  haproxy 
    group  haproxy 
    daemon 
#--------------------------------------------------------------------- 
# common defaults that all the 'listen' and 'backend' sections will 
# use if not designated in their block 
#--------------------------------------------------------------------- 
defaults 
    mode  http 
    log   global 
    option  abortonclose 
    option  dontlognull 
    option  httpclose 
    option  httplog 
    option  forwardfor 
    option  redispatch 
    timeout connect 10000 # default 10 second time out if a backend is not found 
    timeout client 300000 # 5 min timeout for client 
    timeout server 300000 # 5 min timeout for server 
    stats  enable 

listen http_proxy localhost:81 

    balance  roundrobin 
    option  httpchk GET /empty.html 
    server  server1 myip:80 maxconn 15 check inter 10000 
    server  server2 myip:80 maxconn 15 check inter 10000 

Como se puede ver que es sencillo, pero estoy un poco confundido acerca de cómo funcionan las propiedades maxconn.

Hay uno global y el maxconn en el servidor, en el bloque de escucha. Mi pensamiento es el siguiente: el global maneja la cantidad total de conexiones que haproxy, como servicio, hará cola o procesará al mismo tiempo. Si el número supera ese límite, ¿mata la conexión o se agrupa en algún socket de Linux? No tengo idea de lo que sucede si el número supera a 4000.

Luego tiene la propiedad maxconn del servidor establecida en 15. En primer lugar, configuré eso en 15 porque mi php-fpm, esto está reenviando a un archivo por separado servidor, solo tiene tantos procesos secundarios que puede usar, así que me aseguro de agrupar las solicitudes aquí, en lugar de hacerlo en php-fpm. Lo cual creo que es más rápido.

Pero volviendo al tema, mi teoría acerca de este número es que cada servidor en este bloque solo recibirá 15 conexiones a la vez. Y luego las conexiones esperarán por un servidor abierto. Si tuviera las cookies activadas, las conexiones esperarían al servidor CORRECTO abierto. Pero yo no.

Así que las preguntas son:

1. ¿Qué pasa si las conexiones globales obtener por encima de 4000? ¿Ellos mueren? ¿O agrupación en Linux de alguna manera?
2. ¿La conexión global está relacionada con las conexiones del servidor, aparte del hecho de que no puede tener un número total de conexiones de servidor mayor que global?
3. Al calcular las conexiones globales, ¿no debería ser la cantidad de conexiones agregadas en la sección del servidor, más un cierto porcentaje para la agrupación? Y, obviamente, tiene otras restricciones en las conexiones, pero en realidad es la cantidad que desea enviar a los apoderados?

Gracias de antemano.

Answer 1

Willy me consiguió una respuesta por correo electrónico. Pensé que lo compartiría. Sus respuestas están en negrita.

tengo una pregunta sobre mi config haproxy:

#--------------------------------------------------------------------- 
    # Global settings 
    #--------------------------------------------------------------------- 
    global 
     log   127.0.0.1 syslog emerg 
     maxconn  4000 
     quiet 
     user  haproxy 
     group  haproxy 
     daemon 
    #--------------------------------------------------------------------- 
    # common defaults that all the 'listen' and 'backend' sections will 
    # use if not designated in their block 
    #--------------------------------------------------------------------- 
    defaults 
     mode  http 
     log   global 
     option  abortonclose 
     option  dontlognull 
     option  httpclose 
     option  httplog 
     option  forwardfor 
     option  redispatch 
     timeout connect 10000 # default 10 second time out if a backend is not found 
     timeout client 300000 # 5 min timeout for client 
     timeout server 300000 # 5 min timeout for server 
     stats  enable 

    listen http_proxy localhost:81 

     balance  roundrobin 
     option  httpchk GET /empty.html 
     server  server1 myip:80 maxconn 15 check inter 10000 
     server  server2 myip:80 maxconn 15 check inter 10000 

Como se puede ver que es sencillo, pero estoy un poco confundido acerca de cómo funcionan las propiedades maxconn.

Hay uno global y el maxconn en el servidor, en el bloque de escucha.

Y también hay otro en el bloque de escuchar que por defecto es algo como 2000.

Mi pensamiento es la siguiente: el global gestiona el número total de conexiones que HAProxy, como un servicio, will que o process a la vez.

Correcto. Es el número máximo de conexiones simultáneas por proceso.

Si el número se pone por encima de eso, ¿mata la conexión o agrupa en algún socket linux ?

Más tarde, simplemente deja de aceptar nuevas conexiones y permanecen en la cola de socket en el kernel. El número de sockets queuable se determina en por el mínimo de (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog, y escucha el bloque maxconn).

que no tienen idea de lo que sucede si el número se hace mayor que 4000.

El exceso de conexiones esperar a otro para completar antes de ser aceptado . Sin embargo, mientras la cola del kernel no esté saturada, el cliente ni siquiera lo nota, ya que la conexión se acepta en el nivel de TCP pero no se procesa. Entonces, el cliente solo nota algún retraso para procesar la solicitud. Pero en la práctica, el maxconn del bloque de escucha es mucho más importante, ya que de forma predeterminada es más pequeño que el global. El maxconn de escucha limita el número de conexiones por escucha. En general, es aconsejable configurar para la cantidad de conexiones que desee para el servicio, y configurar el maxconn global al número máximo de conexiones que permita que maneje el proceso haproxy. Cuando tiene un solo servicio, ambos pueden establecerse en el mismo valor. Pero cuando tiene muchos servicios, puede entender fácilmente que hace una gran diferencia, ya que no necesita un solo servicio para tomar todas las conexiones y evitar que otros funcionen.

Entonces usted tiene la propiedad maxconn servidor fijado en 15. En primer lugar, he de poner que al 15 porque mi php-pies por minuto, esto es el reenvío a en un servidor independiente, sólo se tiene tantos procesos hijo se puede utilizar , así que me aseguro de agrupar las solicitudes aquí, en lugar de en php-fpm. Lo cual creo que es más rápido.

Sí, no sólo debe ser más rápido, pero permite haproxy encontrar otro servidor disponible siempre que sea posible, y también permite que matan el pedido en la cola si el cliente golpea "parada" antes de la conexión es reenviado al servidor.

Pero volviendo al tema, mi teoría acerca de este número es que cada servidor en este bloque solo recibirá 15 conexiones a la vez. Y luego las conexiones esperarán por un servidor abierto. Si tuviera las cookies activadas, las conexiones esperarían para el servidor abierto CORRECT. Pero yo no.

Ese es exactamente el principio. Hay una cola por proxy y una cola por servidor . Las conexiones con una cookie de persistencia van a la cola del servidor y al otras conexiones van a la cola del servidor proxy. Sin embargo, dado que en su caso no se configuró ninguna cookie , todas las conexiones van a la cola proxy. Puede mirar en el diagrama doc/queuing.fig en fuentes haproxy, si lo desea, explica cómo/dónde se toman las decisiones.

Así que las preguntas son:

1. ¿Qué pasa si las conexiones globales ponen por encima de 4000? ¿Ellos mueren? O grupo en Linux de alguna manera?

   Están en la cola en linux. Una vez que abruma la cola del núcleo, entonces están caídos en el kernel.

2. son la conexión global en relación con las conexiones de servidor, que no sea el hecho de que no se puede tener un número total de conexiones de servidor mayor que global?

   No, las configuraciones de conexión global y del servidor son independientes.

3. Al calcular las conexiones globales, ¿no debería ser la cantidad de conexiones añadido en la sección de servidor, más un cierto porcentaje de puesta en común? Y, obviamente, usted tiene otras limitaciones en las conexiones, pero realmente es la cantidad que desea enviar a los apoderados?

   Has acertado. Si el tiempo de respuesta de su servidor es corto, no hay nada incorrecto en al poner en cola miles de conexiones para atender solo unas pocas a la vez, porque reduce sustancialmente el tiempo de procesamiento de la solicitud. Prácticamente, estableciendo una conexión hoy en día lleva unos 5 microsegundos en una LAN gigabit . Por lo tanto, tiene mucho sentido permitir que haproxy distribuya las conexiones lo más rápido posible desde su cola a un servidor con un maxconn muy pequeño. Recuerdo que un sitio de juegos puso en cola más de 30000 conexiones simultáneas y se ejecutaba con una cola de 30 por servidor. Era un servidor Apache, y apache es mucho más rápido con un número pequeño de conexiones que con números grandes . Pero para esto realmente necesita un servidor rápido, porque no desea desea tener todos sus clientes en cola esperando una ranura de conexión porque el servidor está esperando una base de datos, por ejemplo. También algo que funciona muy bien es dedicar servidores. Si su sitio tiene muchas estadísticas, puede dirigir las solicitudes estáticas a un grupo de servidores (o cachés) para que no coloque en cola solicitudes estáticas y que las solicitudes estáticas no consuman ranuras de conexión caros. Con la esperanza de que esto ayude a , Willy