Me：一般来说nginx和FastCGI都是新手，如果这是一个很明显的老式的道歉，但是谷歌search给了我很多人推荐的随机configuration值，但没有人解释他们的决定背后的原因。
nginx worker_process和PHP-FPM worker之间有什么关系？ 更多的nginx工作者意味着更多的PHP-FPM工作者，还是他们不相关？
我对这个如何在高层工作的理解是
我不清楚PHP-FPM是否会产生一个新的subprocess，以及哪个nginx工作进程正在与之交谈。 即如果你有两个相同的Web服务器，一个worker_process = 4 ，另一个worker_process = 8 ，他们都看到相同的networkingstream量，一个服务器会创build更多的PHP-FPMsubprocess比另一个？ 还是我在这里说了些蠢话，说明我错过了一个基本的概念？ （如果是这样，什么？）
没有试图解决一个具体的问题 – 只是试图学习如何推理nginx和php-fpm的行为，所以我可以促成规模和性能头脑风暴/故障排除。
Nginx的工作进程连接到php-fpm。 但是，他们通过创buildasynchronous连接来实现这一点，将它们视为正常的上游，就像其他任何连接一样。
Nginx是一个事件驱动的应用程序，这意味着它所做的大部分I / O工作，特别是连接到上游，是asynchronous的。 所以一个工作进程在任何时候都可以与上游有任何连接。
PHP-FPM将产生（或者，理想情况下出于性能的原因，使用一个已经产生但未使用的进程）为它收到的每个请求。
所以，考虑到这些，一般两者之间没有直接的关系。 您将始终有nginx中定义的工作进程数量，但是大多数情况下，php-fpm进程的数量会根据收到的请求数量而变化，这与nginx worker的数量没有直接关系stream程。
有人可能会争辩说，如果在nginx中启用fastcgi Keepalive，那么php-fpm进程将会保持更长的时间。 考虑到每个工作进程为使用keepalive的上游获取自己的连接池，可能会导致php-fpm为每个工作进程始终运行更多的进程。 然而，fastcgi keepalive在php-fpm中被打破，据我所知，所以它不应该是一个问题:)。
nginx worker_process es和php-fpm子之间没有内在联系。 他们甚至不必在同一台机器上运行！ 但是，如果他们在同一台机器上，他们可以争夺CPU（这通常不是问题，因为与PHP相比，nginx只需要很less的CPU）。