与不需要 VM 的已编译程序一起使用时，CGI 是否仍然很慢？答案

【问题标题】：Is CGI still slow when used with a compiled program that doesn't require a VM?与不需要 VM 的已编译程序一起使用时，CGI 是否仍然很慢？
【发布时间】：2012-06-15 21:17:08
【问题描述】：

当我学习 CGI 时，我了解到可以使用任何编程语言将其输出挂钩到 http 响应消息，而它的输入是 http 请求消息。很多文章我都在 Perl 的上下文中谈论 CGI，这是因为 Perl 是与 CGI 结合使用的最常见的语言吗？

我想知道的是，如果 CGI 连接到用 C/C++ 编写的程序，它仍然会比使用 PHP 慢吗？

【问题讨论】：

这个问题太模糊了，无法回答。定义“更快”、“最常见”和“慢”。相比什么？做什么？您要求讨论 C/C++ vs Perl vs PHP，这不是一个讨论站点。请编辑您的问题，使其更具体且不易引起意见。
你到底想做什么？您可以将 Servlet 与 java 一起使用。但这一切都取决于您到底想做什么。
即使必须为用 C/C++ 编写的程序启动一个新进程，使用 CGI，由于 PHP 是解释的，那不总是比使用 PHP 更快吗？
一磅一磅，它可能会更快，但可能没有您对常见 Web 请求的想象那么快。当然，用 C/C++ 编写意味着你失去了 Perl/PHP 等的整个 CGI 堆栈。一个折衷的办法是将冗长的计算移到语言之外（例如通过本机函数接口），在处理过程中不应该做太多的计算客户的要求。

标签： php web-services perl cgi

【解决方案1】：

CGI 是表示应用程序应如何交互的标准，而不是特定程序本身。
CGI 通常太慢的原因是它需要为请求启动一个进程，并在该请求结束时关闭。

FastCGI 与 CGI 的不同之处在于它允许一个进程处理多个请求（它维护一个请求处理器池）。这样可以避免大多数传入请求的冗长进程启动/关闭。

有关 CGI 及其“继任者”的更多信息，请查看http://en.wikipedia.org/wiki/Common_Gateway_Interface#Drawbacks

考虑到这一点，性能特征不仅取决于语言及其实现，还取决于用于处理请求的接口。

对于许多简单的请求，进程启动时间可能会远远超过处理时间，这使得语言 X 与 Y 的论点没有实际意义。

【讨论】：

人们应该记住这句话，“它很慢，因为它做了很多事情。”正如您所提到的，对于 CGI，通常启动成本是昂贵的，而现在 CGI 几乎已被持久进程所取代。应用程序运行后，解释型语言的性能通常很好。在将 C/C++ 实体（如哈希、抽象数据结构、引用计数、独立于较低级别类型的标量类型等）分层之后，您又回到了解释语言中内置的相同脂肪，但具有所有不愉快的低级语言。