值得在 Apache 2 上使用 Perl CGI::Fast 吗？
我知道这听起来像是 ServerFault 的问题，但我知道当服务器陷入困境时，开发人员经常受到指责，所以我认为这里的帖子可能对仍在网络上使用 Perl 的人。
故事：
我们的旧 Apache 服务器上的失效进程存在严重问题，因此我们决定迁移到 Apache 2。无可否认，新服务器的性能要好得多。然而，测试表明，在重负载（每分钟约 100 个用户）下，失效进程开始在服务器上快速启动，并且使用 SSH 可以清楚地看出这些进程正在使用 CPU。为了克服这些问题，我们决定实施 CGI::Fast，它是一种 Perl 中的“http://www.fastcgi.com”rel="nofollow noreferrer">FastCGI。有了这个，僵尸就消失了，但是服务器的性能并没有更好地应对。
结果让我假设如果 Apache 实现 CGI::Fast 确实没有意义无论如何，2都会有效地回收资源。
你们中有人得出了不同的结论吗？
I know this sound like a question for ServerFault but I know that developers often get the blame when servers are struggling so I thought a post here might be useful to people who still use Perl on the web.
THE STORY:
We had serious issues with defunct processes on our old Apache server so we decided to move to Apache 2. The new server performs much better, no denying that. Tests reveal however, that under a heavy load (~100 users per minute) defunct processes start quickly ramping up on the server and using SSH it is clear that these processes are using the CPU. To overcome these issues we decided to implement CGI::Fast which is a type of FastCGI in Perl. Having that in place the zombies are gone, however performance wise the server is not coping any better.
The results led me to assume that there isn't really a point implementing CGI::Fast if Apache 2 will efficiently reclaim the resources anyway.
Does any of you have come to a different conlusion?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在我看来，除了 2011 年基于 PSGI/Plack 的解决方案之外，不值得转向任何其他解决方案，独立于您提到的任何其他细节。
In my opinion it’s not worth moving to anything but a PSGI/Plack-based solution in 2011, independent of any other details you mentioned.
FastCGI 比普通 CGI 更快，因为 Apache 不必为每个新请求加载 perl。但是，需要重新编写脚本以消除每个请求都执行一次的假设。 FastCGI 脚本的核心通常代表某种类型的事件循环，处理传入的请求。
您可以将 CGI::Fast 用于纯 CGI 脚本，而无需围绕事件循环重新编写脚本，但您会丢失“快速”部分FastCGI 的这种方式，因为 perl 仍然需要为每个脚本运行一次。
仅当 CGI 脚本的最大部分是加载 perl 或执行一次性代码时，FastCGI 才会提供很大的好处。对于许多 Web 应用程序来说，这是事实。但是，如果您的脚本需要为每个请求执行大量工作，从而加载 perl 的开销很小，那么使用 FastCGI 不会带来很大的性能优势。
FastCGI is faster than plain CGI because Apache doesn't have to load perl for each new request. However, the scripts need to be reworked to remove the assumption that they are executed once for each request. A FastCGI script at its core typically represents some type of event loop, processing the requests as they come in.
You can use CGI::Fast for plain CGI scripts without reworking the script around an event loop, but you lose the "Fast" part of FastCGI this way, as perl still needs to be run once for every script.
FastCGI also only provides a large benefit if the biggest part of your CGI script is loading perl or executing one-time code. For many web applications, this is true. However, if your script needs to do a lot of work for each request, such that the overhead of loading perl is small, then you won't see a big performance benefit by using FastCGI.
CGI
除了小型网站之外，它的效率太低了。 CGI 为每个传入请求生成一个新进程来执行脚本，这是一种资源密集型且低效的执行方式。难怪随着 Web 应用程序变得更加复杂，它会随着时间的推移而逐渐消失。
FastCGI 的引入是为了避免 Apache 进程内运行语言的一些问题，以及避免 CGI 的低效率。
FastCGI 应用程序在 Web 服务器（Apache 或其他）之外执行，并使用套接字等待来自 Web 服务器的请求。 Web 服务器和 FastCGI 应用程序甚至可以位于不同的物理机器上并通过网络进行通信。
由于 Web 服务器和应用程序进程是分开的，因此可以实现更好的隔离。
CGI
It was too inefficient for anything but small sites. CGI spawns a new process for every incoming request to execute a script, a very resource intensive and inefficient way of doing things. No wonder it faded away over time as web applications became more complex.
FastCGI was introduced to avoid some of the issues with running languages inside the Apache process, as well as avoiding the inefficiency of CGI.
A FastCGI application is executed outside of the web server (Apache or other wise), and waits for requests from the web server using a socket. The web server and the FastCGI application can even be on separate physical machines and communicate over the network.
Because the web server adn the application processes are separate better isolation is possible.