在 Apache 2 上使用 Perl CGI::Fast 是否值得？

Question

我知道这听起来像是向ServerFault 提出的问题，但我知道当服务器陷入困境时开发人员经常会受到指责，因此我认为此处的帖子可能对仍在网络上使用Perl 的人有用。

故事：

我们的旧 Apache 服务器上的已失效进程存在严重问题，因此我们决定迁移到 Apache 2。不可否认，新服务器的性能要好得多。然而，测试表明，在重负载（每分钟约 100 个用户）下，失效的进程开始在服务器上快速启动，并且使用 SSH 很明显这些进程正在使用 CPU。为了克服这些问题，我们决定实现CGI::Fast，它是Perl 中FastCGI 的一种类型。有了这个，僵尸就消失了，但是服务器的性能并没有更好。

结果让我认为，如果 Apache 2 无论如何都能有效地回收资源，那么实现 CGI::Fast 真的没有意义。

你们有没有得出不同的结论？

Answer 1

在我看来，除了您提到的任何其他细节之外，在 2011 年，除了基于 PSGI/Plack 的解决方案之外，没有任何价值。

• Plack ecosystem is so much greater 比 FastCGI 的。 （优势）
• 您可以部署到比FastCGI supports 更多的服务器。 （优势）
• 您可以运行未经修改的 CGI 脚本，例如Plack::App::CGIBin 而 CGI::Fast 需要重写。 （优势）
• 重写 CGI 程序以符合 PSGInterface 比将其重写为 CGI::Fast 需要更多的努力。 （缺点）

Answer 2

FastCGI 比普通 CGI 更快，因为 Apache 不必为每个新请求加载 perl。但是，需要重新编写脚本以消除对每个请求执行一次的假设。 FastCGI 脚本的核心通常代表某种类型的事件循环，在请求进入时对其进行处理。

您可以将 CGI::Fast 用于纯 CGI 脚本，而无需围绕事件循环重新编写脚本，但是这样会丢失 FastCGI 的“Fast”部分，因为 perl 仍然需要为每个脚本运行一次。

如果您的 CGI 脚本的最大部分是加载 perl 或执行一次性代码，FastCGI 也只会提供很大的好处。对于许多 Web 应用程序来说，这是真的。但是，如果您的脚本需要为每个请求执行大量工作，从而加载 perl 的开销很小，那么使用 FastCGI 将不会看到很大的性能优势。

Answer 3

CGI

除了小型网站之外，这对于其他任何东西来说都太低效了。 CGI 为每个传入请求生成一个新进程以执行脚本，这是一种资源密集且效率低下的处理方式。难怪随着 Web 应用程序变得越来越复杂，它随着时间的推移逐渐消失。

FastCGI 的引入是为了避免在 Apache 进程中运行语言的一些问题，以及避免 CGI 的低效率。

FastCGI 应用程序在 Web 服务器（Apache 或其他方式）之外执行，并使用套接字等待来自 Web 服务器的请求。 Web 服务器和 FastCGI 应用程序甚至可以位于不同的物理机器上并通过网络进行通信。

因为 Web 服务器和应用程序进程是分开的，所以可以更好地隔离。