http - 为什么选择 FastCGI 而不是使用编译语言或守护进程的 CGI

Question

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

1. 我明白了，当对每个请求使用解释脚本(如 Perl)时，CGI 可能会很慢，因为解释器需要时间来启动和加载库。在使用 C 或 Rust 等编译语言时，FastCGI 是如何改进 CGI 的？

2. 难道我不能通过启动一个守护进程来重新创建 FastCGI 所做的事情，该守护进程与小型(因此性能良好)的 CGI shell 脚本联系吗？

Answer 1

老实说，您可以用 C 语言编译一个原型(prototype)并尝试一下。有趣的是，人们一口气说“预优化是万恶之源”，第二天又说“不要使用 CGI，因为 fork/exec 性能很差”。编译语言比解释语言有很多优势，不仅仅是速度(类型的早期错误检测)，而且在我便宜的 Arch Linux 开发笔记本电脑上，我可以让 Apache fork/exec 我的 CGI 脚本每秒 3000 多次。

与具有 275 层间接寻址的 PHP 等整体“框架”相比，CGI 的类 Unix 简单性(标准输入和输出)非常吸引人。如果 CGI 对于您的 Suse 案例确实表现不佳，那么 CGI 和 FastCGI 之间的区别可能只是一个小接口(interface)，所以当它发生时就处理它。