我查看了 FastCGI (fcgi-2.4.0) 的源代码，实际上没有 fork 的迹象。 如果我是正确的，Web 服务器会为 FastCGI 模块(在其中编译或作为 SO/DLL 加载)生成一个进程，并将主套接字(通常是端口 TCP:80)的控制权交给它。
在 *nix 上，FastCGI 模块使用文件写锁(libfcgi/os_unix.c:989)在整个文件描述符(实际上是监听套接字)上“锁定”该套接字；这样，当新连接进入时，只有 FastCGI 模块能够处理这些连接。 在移交给 HTTP 请求处理之前释放传入的套接字锁。
由于 FastCGI 模块不是多进程/线程(没有 内部 fork/pthread_create 的使用)我假设多个同时连接的并发处理是通过从 Web 服务器(通过 OS_SpawnChild)spwaning 获得的) 的 n 个 FastCGI 模块进程。 例如，如果我们生成 3 个 FastCGI 进程(Apache 调用 3 个 OS_SpawnChild)，这是否意味着我们最多只能同时处理 3 个请求？
A) 我对 FastCGI 工作方式的看法是否正确？
B) 如果操作系统生成新进程/创建与本地数据库的连接的成本可以忽略不计，那么与老式可执行方法相比，FastCGI 有哪些优势？
谢谢， 艾玛! :-)
最佳答案
FastCGI 相对于普通 CGI 的速度增益在于进程是持久的。例如如果您有任何要打开的数据库句柄，您可以打开一次。任何缓存都一样。
主要的好处是不必创建新的 php/perl/etc。每次都需要口译员，这会花费大量时间。
如果你想处理多个并发连接，你必须有多个进程 FastCGI 进程在运行。 FastCGI 不是一种通过任何类型的特殊并发来处理更多连接的方法。这是一种加速单个请求的方法，这反过来将允许处理更多请求。但是是的，你是对的，更多的并发请求需要更多的进程运行。
关于c++ - FastCGI 如何在 Web 服务器上工作(例如 Apache 2.2+)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1222510/