Nginx worker_connections“设置了工作进程可以打开的最大同时连接数。该数目包括所有连接（例如，与代理服务器的连接等），而不仅包括与客户端的连接。另一个考虑因素是实际的同时连接数不能超过当前最大打开文件数限制”。我对此有几个疑问：

1. 最佳或推荐值应该是多少？
2. 使用大量工作人员连接的不利之处是什么？

让我们采取务实的方法。

所有这些限制都是在上个世纪硬件速度缓慢且昂贵的情况下经过硬编码和设计的。现在是2016年，一个普通的Wall-mart烤面包机可以处理的请求多于默认值。

默认设置实际上很危险。在网站上拥有数百个用户并不令人印象深刻。

worker_process

一个相关的设置，让我们在讨论主题时对其进行解释。

nginx作为负载均衡器：

• 1个用于HTTP负载平衡的工作程序。
• 每个内核1个工作线程，用于HTTPS负载平衡。

Nginx作为Web服务器：

这是一个棘手的问题。

一些应用程序/框架/中间件（例如php-fpm）在nginx之外运行。在那种情况下，一个nginx worker就足够了，因为通常是外部应用程序在进行繁重的处理并消耗资源。

而且，某些应用程序/框架/中间件一次只能处理一个请求，并且会反省以使它们过载。

一般来说，一个工人永远是一个安全的选择。

否则，如果您知道自己在做什么，则可以在每个核心上放置一个工人。我认为这是一种优化，并建议适当的基准测试。

worker_connections

连接总数为worker_process * worker_connections。一半处于负载均衡器模式。

现在我们到达烤面包机部分。有许多严重被低估的系统限制：

• ulimits是linux上每个进程最多1k个打开文件（软盘为1k，某些发行版为4k硬）
• systemd限制与ulimit大致相同。
• nginx默认为每个工作人员512个连接。
• 可能还有更多：SELinux，sysctl，supervisor（每个发行版和版本略有不同）

1k worker_connections

安全默认值是到处都放置1k。

它足够高，超过了大多数内部站点和未知站点。它足够低，不会达到任何其他系统限制。

10k worker_connections

拥有成千上万的客户非常普遍，尤其是对于公共网站而言。由于默认值较低，我不再统计看到的网站数量下降了。

可接受的最小生产量为10k。必须增加相关的系统限制以允许它。

没有太高的限制（如果没有用户，限制就没有效果）。但是，过低的限制是非常真实的事情，会导致用户被拒绝和网站死机。

超过10k

10k很容易。

我们可以设置一个任意的1000kk限制（毕竟这只是一个限制），但这没有多大实际意义，我们永远也不会获得该流量，也无法采取任何措施。

让我们坚持10k作为合理设置。想要（并且确实可以做）更多的服务将需要特殊的调整和基准测试。

特殊方案：高级用法

有时，我们知道服务器没有太多资源，并且我们预期峰值不会做太多。我们宁愿拒绝用户也不愿尝试。在这种情况下，请设置合理的连接限制并配置良好的错误消息和处理。

有时，后端服务器运行良好且运行良好，但只能承受一定的负载，仅此而已，一切很快就会消失。我们宁愿放慢脚步，也不愿让服务器崩溃。在那种情况下，配置严格限制的队列，让Nginx缓冲所有热量，同时以限制的速度耗尽请求。

ulimit -a 会告诉您系统允许一个进程使用多少个打开文件。

此外，net.ipv4.ip_local_port_range设置每个IP启用的套接字的总范围。

因此，您的连接worker_connections数不能超过其中的任何一个，否则您的客户端连接将排队直到net.core.netdev_max_backlog-TCP队列的总大小。

请记住，如果您使用nginx作为反向代理，则每个连接使用两个套接字。您可能希望net.ipv4.tcp_fin_timeout与其他与tcp相关的超时一起玩一些，以尝试快速切换套接字状态。需要注意的另一件事是，每个套接字分配TCP内存堆栈的内存，您也可以使用来设置TCP内存堆栈的一些限制，sysctl只要您有CPU和足够的文件处理程序，就可以对RAM施加更大的压力。

仅供参考，有可能拥有足够的计算资源，使一台服务器具有32GB的ram和一些虚拟网络接口来处理1MM同时连接，并使用sysctl进行一些内核调整。在我的测试中，当处理1MM以上并发送大约700Bytes的有效负载时，服务器需要大约10秒钟来更新大约1.2MM的并发客户端。接下来是通过绑定一些额外的NIC并放弃虚拟NIC来增加网络带宽。给定有效载荷，带宽和合理的时间来更新所有客户端，可以与超过1.2MM的客户端实现伪近实时通信。

调整愉快！

可以通过测试发现合适的大小，因为它会根据Nginx处理的流量类型而变化。

从理论上讲，nginx可以处理：最大客户端= worker_processes * worker_connections（* = multiply）和worker_processes =处理器数量

要查找处理器，请使用：grep Processor / proc / cpuinfo | wc -l

当您可能会受到资源限制时，设置下限可能很有用。某些连接，例如，保持活动连接（不仅与客户端保持连接，与上游服务器））有效地浪费了资源（即使nginx非常有效），并且不需要通用服务器的正确操作，这意味着可以安全地删除它们，以为其余操作提供更多资源。

因此，具有较低的资源限制将向nginx指示您可能缺乏物理资源，应该将可用资源分配给新的连接，而不是为空闲的保持活动连接提供服务，而以较新的连接无法建立为代价服务于更紧迫的需求。

推荐值是多少？这是默认值。

默认值全部记录在文档中：

默认值：worker_connections 512;

并可以在在源代码级证实event/ngx_event.c，太

13＃定义DEFAULT_CONNECTIONS 512

Marcel的答案确实需要赞成！如果将ulimits的默认值设置为1k左右，则应将max_connections设置为相同的值，否则将max_connections设置为10k没有任何好处。

如果“您的worker_connections不能超过其中的任何一个，否则您的客户端连接将排队，或者您的客户端连接将排队，直到net.core.netdev_max_backlog-TCP队列的总大小。”

只要ulimit允许，就可以打开单个进程。num_workers * max_connections是公式，但是要考虑合理的值，必须考虑外部loadbalancer / proxy最大连接数和ulimit。将max_connection设置为非常高的值可能会适得其反，因为ulimits是一个限制因素。