7

我查看了 FastCGI (fcgi-2.4.0) 的来源，实际上没有分叉的迹象。如果我是正确的，Web 服务器会为 FastCGI 模块生成一个进程（在其中编译或作为 SO/DLL 加载）并处理对主套接字（通常是 TCP:80 端口）的控制。

在 *nix 上，FastCGI 模块在整个文件描述符（实际上是监听套接字）上使用文件写锁（libfcgi/os_unix.c:989）“锁定”该套接字；这样，当新连接获得时，只有 FastCGI 模块能够处理这些。传入的套接字锁定在移交给 HTTP 请求处理之前被释放。

正如所见，FastCGI 模块不是多进程/线程（没有内部使用 fork/pthread_create）我假设多个同时连接的并发处理是通过从 n 个 FastCGI 模块进程的 Web 服务器（通过 OS_SpawnChild）生成的。例如，如果我们生成 3 个 FastCGI 进程（Apache 调用 3 x OS_SpawnChild），这是否意味着我们最多只能同时处理 3 个请求？

A) 我对 FastCGI 工作方式的看法是否正确？

B) 如果操作系统产生新进程/创建与本地数据库的连接的成本可以忽略不计，那么 FastCGI 与老式可执行方法相比有什么优势？

谢谢，艾玛！:-)

4

4 回答 4

5

FastCGI 相对于普通 CGI 的速度增益是进程是持久的。例如，如果您有任何要打开的数据库句柄，您可以执行一次。任何缓存都一样。

主要收益来自不必创建新的 php/perl/etc。每次都要翻译，这花费了惊人的时间。

如果您想处理多个并发连接，则必须运行多个进程 FastCGI 进程。FastCGI 不是一种通过任何类型的特殊并发处理更多连接的方法。这是一种加速单个请求的方法，这反过来将允许处理更多请求。但是是的，你是对的，更多的并发请求需要更多的进程运行。

于 2009-08-03T14:34:39.847 回答
4

FastCGI 生成的进程是持久的，一旦处理了请求，它们就不会被杀死，而是被“池化”。

于 2009-08-03T14:13:40.530 回答
2

B，是的，如果生成成本为零，那么传统 CGI 将相当不错。因此，如果您没有很多点击量，普通的旧 CGI 就可以了，请使用它。快速 cgi 的重点是做一些可以从大量持久存储中受益的事情，或者在完成工作之前必须构建的结构，例如对大型数据库运行查询，而您希望将数据库库留在内存中每次要运行查询时都必须重新加载整个 shebang。

当你有很多命中时，这很重要。

于 2011-03-10T01:19:12.710 回答
1

的确，

所以看到（A）没问题，现在（B）呢？如果我说的是可执行文件（正确编译的 C/C++ 程序，而不是像 perl/php/... 这样的脚本），并且如果我们认为进程 spwan 成本和 DB 新连接成本可以忽略不计，那么这种方法 (FastCGI) 只是与普通的 CGI 可执行文件相比，这是一种小小的收获？

我的意思是，鉴于 Linux 在生成（分叉）进程方面非常快，并且如果数据库在本地运行（例如，同一主机 MySQL），则启动新的可执行文件并连接到数据库所需的时间实际上是 0。在这种情况下，无需解释任何内容，只有 Apache C/C++ 模块会比这更快。

使用 FastCGI 方法，那么您更容易受到内存泄漏的影响，因为该过程并非每次都分叉/重新启动...此时，如果您必须在 C/C++ 中开发您的 CGI，那就再好不过了直接使用老式CGI 和/或 Apache C/C++ 模块？

同样，我不是在谈论脚本（perl/php/...），而是在谈论编译后的 CGI。

再次感谢，干杯，Ema！:-)

于 2009-08-03T15:56:49.857 回答