example - haproxy vs nginx

Diferencia entre maxconn global y maxpron haproxy del servidor (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 configuración de 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 puede ver, es sencillo, pero estoy un poco confundido sobre cómo funcionan las propiedades de maxconn.

Existe el global y el maxconn en el servidor, en el bloque de escucha.

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

Mi pensamiento es el siguiente: el global maneja la cantidad total de conexiones que haproxy, como servicio, hará cola o procesará al mismo tiempo.

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

Si el número supera ese límite, ¿mata la conexión o se agrupa en algún socket de Linux?

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

No tengo idea de qué pasa si el número supera los 4000.

El exceso de conexiones espera a que se complete otro antes de ser aceptado. Sin embargo, mientras la cola del kernel no esté saturada, el cliente ni siquiera se da cuenta de esto, 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 por defecto es más pequeño que el global. El maxconn de escucha limita el número de conexiones por oyente. En general, es aconsejable configurarlo para la cantidad de conexiones que desee para el servicio y para configurar el maxconn global con la cantidad máxima 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 comprender fácilmente que hace una gran diferencia, ya que no quiere que un solo servicio tome todas las conexiones y evite que las otras funcionen.

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

Sí, no solo debería ser más rápido, sino que permite a haproxy encontrar otro servidor disponible siempre que sea posible, y también le permite matar la solicitud en la cola si el cliente pulsa "detener" antes de que la conexión se reenvíe 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 al servidor CORRECTO abierto. 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 otras conexiones van a la cola del proxy. Sin embargo, dado que en su caso no se configura ninguna cookie, todas las conexiones van a la cola proxy. Puede ver el diagrama doc / queuing.fig en fuentes haproxy si lo desea, explica cómo / dónde se toman las decisiones.

Entonces las preguntas son:

¿Qué sucede si las conexiones globales superan los 4000? ¿Ellos mueren? ¿O agrupación en Linux de alguna manera?
Están en cola en Linux. Una vez que abruma la cola del kernel, se eliminan en el kernel.
¿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?
No, la configuración de conexión global y del servidor es independiente.
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?
Lo hiciste bien. Si el tiempo de respuesta de su servidor es corto, no hay nada de malo en poner en cola miles de conexiones para atender solo unas pocas a la vez, porque reduce sustancialmente el tiempo de procesamiento de las solicitudes. Prácticamente, establecer 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 ejecutó 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 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 ponga en cola las solicitudes estáticas y que las solicitudes estáticas no consuman ranuras de conexión costosas. Esperando que esto ayude, Willy

Tengo una pregunta sobre mi configuración de haproxy:

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

Existe el 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 qué pasa si el número supera los 4000.

Entonces las preguntas son:

¿Qué sucede si las conexiones globales superan los 4000? ¿Ellos mueren? ¿O agrupación en Linux de alguna manera?
¿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?
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.