为什么选择带有编译语言或守护程序的FastCGI而不是CGI

Question

我正在阅读CGI和FastCGI，想知道为什么要创建后者。我经常读到的原因是，这样可以省去为每个请求创建新流程的开销，但是我无法想象这是一个如此巨大的性能问题。

1. 我看到，对于每个请求使用解释脚本（例如Perl）时，CGI可能会变慢，因为解释器需要时间来启动和加载库。使用C或Rust等编译语言时，FastCGI与CGI相比有何改进？

2. 我是否只能通过启动守护进程来重新创建FastCGI的功能，而这个守护进程是由小型（因此性能良好的）CGI Shell脚本联系的？

Answer 1

老实说，您可以使用C编译原型并进行尝试。有趣的是，人们一口气说“预优化是万恶之源”，而在第二天“不要使用CGI，因为fork / exec的表现不佳”。编译语言不仅比速度更快（对类型进行早期错误检测），还具有Interptretted的许多优点，并且在我便宜的Arch Linux开发笔记本电脑上，我可以让Apache fork / exec每秒执行CGI脚本3000次以上。

与Unix等具有275个间接层的整体式“框架”相比，类Unix的CGI简单性（标准输入和输出）非常吸引人。而且，如果CGI在您的Suse案例中确实不能很好地执行，则CGI和FastCGI之间的差异可能只有一个很小的接口，所以只要在发生这种情况时就对其进行处理即可。

Answer 2

这几乎是一个常见问题解答。在开始新问题之前，您应该先用Google搜索一下。无论如何..请看下面的链接。

Differences and uses between WSGI, CGI, FastCGI, and mod_python in regards to Python?

此外，请查看Apache文档的mod_cgi和mod_fcgi页面。对于

1. 没有CGI不会因为使用脚本语言而变慢，尤其是不是Perl。 CGI由于其工作原理而变慢。关于它的改进，您必须阅读有关FastCGI的更多信息。

2. 您仍然不了解FastCGI的功能，所以不。