全局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你想要发送给代理？

先谢谢你。

Answer 1

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

我有一个关于我的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），以便您不会在其上静态请求排队，并且静态请求不会吃昂贵的连接插槽。 希望这可以帮助，威利