迄今为止的事实

根据 ”mod_fcgi 不是 mod_fastcgi 的替代品 http://www.apachelounge.com/viewtopic.php?t=4385” and “mod_fcgid 和多线程 FastCGI 应用程序的问题 http://mail-archives.apache.org/mod_mbox/httpd-users/201008.mbox/%3C4C7C286B.6020703@codexterous.com%3E”, mod_fcgid，并不是为了期望 FastCGI 服务器能够同时处理多个请求，即不是为了期望 FastCGI 服务器是多线程的。

前者说：

它们都支持已发布的“FastCGI”协议，但是 他们控制 FastCGI 服务器的方式有很大不同。 mod_fcgid 快速消除 FastCGI 服务器并启动 新的。

后者说：

看来 mod_fcgid 不知道我的服务器 是多线程的，能够处理多个请求。

这只是其中的两句话，其他地方还有一些。

连续发行

线程不仅可以节省 CPU 和内存，避免创建新进程的开销（众所周知，创建线程比创建进程更轻），而且可以通过硬件或操作系统性能来减轻开销；这也是一个逻辑问题，不太容易缓解：线程属于同一个进程，这不仅是性能，而且是逻辑，例如。进程无法共享线程可以共享的内容，因为进程是隔离运行的（模 IPC，但这并不相同）。

至少出于这个逻辑原因，可能会提出多线程 FastCGI 服务器的问题。当 FastCGI 服务器被设计为多线程服务器时，它可能拥有一个对所有请求处理程序来说都是全局的上下文（在进程之间共享可能会很大且成本高昂）。为每个并发请求分叉一个新进程不再能够确保公共上下文。

问题

上述两段引文是否仍然属实（一个是 2011 年，另一个是 2010 年）？我在网上搜索了该主题，但找不到任何相关内容。如果它仍然是真的，那么它会永远是真的吗？或者是否有一个预期的计划？mod_fcgid，了解多线程 FastCGI 服务器并接受它们可能被设计为处理多个并发请求？

我无法回答您关于 mod_fcgid 的确切问题，但 Apache 已经继续前进，Apache 2.4 中现在的首选方法是使用 mod_proxy_fcgi，http://httpd.apache.org/docs/trunk/mod/mod_proxy_fcgi.html http://httpd.apache.org/docs/trunk/mod/mod_proxy_fcgi.html.

它确实处理多个并发请求。通常，您可以将请求传递给 php-fpm 处理程序。