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

Question

我知道这听起来像ServerFault的问题，但我知道开发人员经常会在服务器挣扎时受到指责，所以我认为这里的帖子可能对那些仍在使用Perl的人有用。幅。

故事：

我们在旧的Apache服务器上出现了已解决过程的严重问题，因此我们决定迁移到Apache 2.新服务器执行得更好，不可否认。然而，测试显示，在负载很重（每分钟约100个用户）的情况下，已停止的进程会在服务器上快速启动并使用SSH显然这些进程正在使用CPU。为了克服这些问题，我们决定在CGI::Fast中实施FastCGI Perl。有了这个僵尸已经消失，但是性能明智，服务器没有更好的应对。

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

你们中有没有人有过不同的结论？

Answer 1

在我看来，除了基于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的“快速”部分，因为perl仍然需要为每个脚本运行一次。

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

Answer 3

<强> CGI

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

引入了

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

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

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