时间戳

首页 > 解决方案 > 为什么选择 FastCGI 而不是带有编译语言或守护进程的 CGI

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

问题描述

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

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

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

标签： httpcgidaemonfastcgi

解决方案

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

与 PHP 等具有 275 层间接层的单体“框架”相比，CGI 的类 Unix 简单性（标准输入和输出）非常有吸引力。如果 CGI 对您的 Suse case 确实表现不佳，那么 CGI 和 FastCGI 之间的差异可能只有一个小接口，所以当它发生时就处理它。

推荐阅读