全局maxconn和服务器maxconn haproxy之间的区别

我有一个关于我的haproxyconfiguration的问题:

#--------------------------------------------------------------------- # 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 

正如你所看到的那样简单,但是我对maxconn属性的工作方式有点困惑。

在监听块中有服务器上的全局和maxconn。 我的想法是这样的:全球一个pipe理haproxy作为一个服务的连接总数,将一次查询或处理。 如果数字超过这个数字,它会杀死连接,或者在某个linux套接字中池? 如果数字超过4000,我不知道会发生什么。

然后你的服务器的maxconn属性设置为15.首先,我把它设置为15,因为我的php-fpm,这是转发到一个单独的服务器上,只有这么多subprocess,它可以使用,所以我确保我在这里汇集请求,而不是在php-fpm中。 我认为更快。

但是关于这个问题,我关于这个数字的理论是每个服务器在这个模块中一次只能发送15个连接。 然后连接将等待一个开放的服务器。 如果我有cookies,连接将等待正确的打开的服务器。 但我不知道

所以问题是:

  1. 如果全球连接达到4000以上,会发生什么? 他们死了吗? 或者在Linux中以某种方式池?
  2. 全局连接是否与服务器连接相关,而不是全局服务器连接总数大于全局?
  3. 在计算全局连接时,不应该是服务器部分中加起来的连接数量加上一定比例的池化? 显然你对连接有其他限制,但是真的有多less你想要发送给代理?

先谢谢你。

威利通过电子邮件给了我一个答案。 我以为我会分享它。 他的回答是粗体的。

我有一个关于我的haproxyconfiguration的问题:

  #--------------------------------------------------------------------- # 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 

正如你所看到的那样简单,但是我对maxconn属性的工作方式有点困惑。

在监听块中有服务器上的全局和maxconn。

监听块中还有另外一个默认为2000的东西。

我的想法是这样的:全球一个pipe理haproxy作为一个服务的连接总数,将一次查询或处理。

正确。 这是每个进程的最大并发连接数。

如果数字超过这个数字,它会杀死连接,或者在某个linux套接字中池?

后来,它只是停止接受新的连接,他们留在内核的套接字队列。 可排队套接字的数量由(net.core.somaxconn,net.ipv4.tcp_max_syn_backlog和监听块的maxconn)的min决定。

如果数字超过4000,我不知道会发生什么。

多余的连接等待另一个完成之后才被接受。 但是,只要内核的队列不饱和,客户端甚至不会注意到这一点,因为连接在TCP级被接受,但是不被处理。 所以客户只会注意到一些延迟来处理请求。 但实际上,监听块的maxconn更重要,因为默认情况下它比全局小。 监听的maxconn限制了每个监听者的连接数量。 一般情况下,最好将其configuration为服务所需的连接数,并将全局maxconnconfiguration为允许haproxy进程处理的最大连接数。 如果只有一个服务,则可以将它们设置为相同的值。 但是当你有很多服务的时候,你可以很容易的理解这个服务会产生巨大的影响,因为你不希望单个服务把所有的连接都拿走,并且阻止其他服务的工作。

然后你的服务器的maxconn属性设置为15.首先,我把它设置为15,因为我的php-fpm,这是转发到一个单独的服务器上,只有这么多subprocess,它可以使用,所以我确保我在这里汇集请求,而不是在php-fpm中。 我认为更快。

是的,不仅它应该更快,而且它允许haproxy尽可能find另一个可用的服务器,并且如果客户端在连接被转发到服务器之前命中“停止”,它允许它杀死队列中的请求。

但是关于这个问题,我关于这个数字的理论是每个服务器在这个模块中一次只能发送15个连接。 然后连接将等待一个开放的服务器。 如果我有cookies,连接将等待正确的打开的服务器。 但我不知道

这正是原则。 有一个每个代理队列和一个每个服务器队列。 与持久性cookie的连接转到服务器队列,其他连接转到代理队列。 但是,因为在你的情况下没有configurationcookie,所有的连接都进入代理队列。 您可以查看haproxy源文件中的doc / queuing.fig图表,说明如何/在何处作出决定。

所以问题是:

  1. 如果全球连接达到4000以上,会发生什么? 他们死了吗? 或者在Linux中以某种方式池?

    他们在linux中排队。 一旦你压倒了内核的队列,那么它们就被放入内核。

  2. 全局连接是否与服务器连接相关,而不是全局服务器连接总数大于全局?

    不,全局和服务器连接设置是独立的。

  3. 在计算全局连接时,不应该是服务器部分中加起来的连接数量加上一定比例的池化? 显然你对连接有其他限制,但是真的有多less你想要发送给代理?

    你做对了。 如果您的服务器的响应时间很短,排队数以千计的连接一次只能服务几个没有任何问题,因为它大大减less了请求处理时间。 实际上,现在build立连接在千兆局域网上需要大约5微秒的时间。 因此,让haproxy尽可能快地将连接从队列分配给一个maxconn很小的服务器是非常有意义的。 我记得有一个游戏网站排队超过30000个并发连接,每个服务器有30个队列。 这是一个Apache服务器,而且Apache的连接数量less于大数量。 但是为此,你真的需要一个快速的服务器,因为你不想让所有的客户端排队等待连接槽,因为服务器正在等待数据库。 另外一个很好的作品是专用服务器。 如果您的站点有许多静态,您可以将静态请求引导到一个服务器池(或caching),以便您不会在其上静态请求排队,并且静态请求不会吃昂贵的连接插槽。 希望这可以帮助,威利