Willy me envió una respuesta por correo electrónico. Pensé que lo compartiría. Sus respuestas están en negrita.
Tengo una pregunta sobre mi configuración 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 acerca de cómo funcionan las propiedades de maxconn.
Está el global y el maxconn en el servidor, en el bloque de escucha.
Y también hay otro en el bloque de escucha que tiene un valor predeterminado como 2000.
Mi pensamiento es el siguiente: el global gestiona el número total de conexiones que haproxy, como servicio, pondrá en cola o procesará al mismo tiempo.
Correcto. Es el número máximo de conexiones simultáneas por proceso.
Si el número supera eso, ¿mata la conexión o se agrupa en algún socket de Linux?
Cuanto más tarde, simplemente deja de aceptar nuevas conexiones y permanecen en la cola de sockets del kernel. El número de sockets que se pueden poner en cola está determinado por el mínimo de (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog y maxconn del bloque de escucha).
No tengo idea de lo que sucede si el número supera los 4000.
Las conexiones en exceso esperan a que se complete otra antes de ser aceptadas. 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 a nivel TCP pero no se procesa. Entonces, el cliente solo nota cierto 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 el número de conexiones que desea para el servicio, y configurar el maxconn global al número máximo de conexiones que deja que maneje el proceso haproxy. Cuando solo tiene un servicio, ambos pueden configurarse con el mismo valor. Pero cuando tienes muchos servicios,
Luego, tiene la propiedad maxconn del servidor establecida en 15. En primer lugar, lo configuré en 15 porque mi php-fpm, esto se reenvía a un servidor separado, solo tiene tantos procesos secundarios que puede usar, así que me aseguro de estar agrupando las solicitudes aquí, en lugar de en php-fpm. Lo que 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 eliminar la solicitud en la cola si el cliente presiona "detener" antes de que la conexión se reenvíe al servidor.
Pero volviendo al tema, mi teoría sobre este número es que a cada servidor en este bloque solo se le enviarán 15 conexiones a la vez. Y luego las conexiones esperarán un servidor abierto. Si tuviera cookies, las conexiones esperarían a que el servidor abierto CORRECTA. Pero no lo hago.
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 del proxy. Puede ver el diagrama doc / queueing.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? ¿Mueren? ¿O agruparse en Linux de alguna manera?
Están en cola en Linux. Una vez que abruma la cola del kernel, se colocan 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 la 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 ¿realmente es cuántas desea enviar a los proxies?
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 solicitudes. Prácticamente, establecer una conexión hoy en día toma alrededor de 5 microsegundos en una LAN gigabit. Así que tiene mucho sentido dejar 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 reducido de conexiones que con un gran número. Pero para esto realmente necesita un servidor rápido, porque no No desea que todos sus clientes estén 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 estáticas, puede dirigir las solicitudes estáticas a un grupo de servidores (o cachés) para que no ponga en cola solicitudes estáticas en ellos y que las solicitudes estáticas no consuman ranuras de conexión costosas. Esperando que esto ayude, Willy