【问题标题】:Are there alternatives to CGI (and do I really need one)?是否有 CGI 的替代品(我真的需要一个)吗?
【发布时间】:2010-09-13 11:26:24
【问题描述】:

我正在设计一个应用程序,它将由 3-4 个服务组成,这些服务作为单独的进程运行并通过合适的 IPC 链接。该系统将有一个网络界面,我想使用那里的任何网络服务器。

应该在某个 URL 下访问 Web 界面,该 URL 允许同一 Web 服务器上的其他 URL 执行完全不同的操作。我打算使用该 URL 下面的路径来指定 Web 界面应该做什么。它具有供其他应用程序通过网络使用以及供人类在浏览器中进行交互的设施。

即兴发挥,我会按以下方式工作:

  • 让网络服务器为它收到的每个请求启动一个 CGI 进程(如 Apache 中的 SetHandler)
  • 让 CGI 连接到 IPC
  • 让它从后端服务获取所需的一切
  • 让 CGI 根据服务的回答返回 HTML / XML 和任何 HTTP 状态

现在,我真正想要的是避免前两个步骤,或者如果我不能,避免第二个步骤,因为我担心我会在不必要的开销上浪费性能(来自其他应用程序的请求可能很频繁)。

例如,PHP 可以打开与 MySQL 数据库的持久连接,这些连接在脚本运行时仍然存在,并且下次不需要重新创建,尽管我不知道它们实际上是如何做到的。另外,据我了解,Apache 模块会在服务器启动时加载一次,因此这可能会删除第一步,但会将我与 Apache 联系起来。

那么,有什么好方法可以将特定 URL 的处理程序挂接到不同的网络服务器?我不想处理 HTTP,否则我可能只是使用代理设置到第二台服务器,但它似乎是在重新发明轮子。如果您认为 CGI 很好,并且有处理类似结构的大量请求的示例,请告诉我。

【问题讨论】:

    标签: cgi ipc


    【解决方案1】:

    即使在中等负载下,CGI 也是一个不可扩展的野兽。 FastCGI 是一个选项,但您可能还会找到一个 mod_XXXX 包,其中 XXXX 是您的语言名称。例如,有一个用于 ruby​​、perl 和 python 的 mod,可能还有一些其他的。

    【讨论】:

      【解决方案2】:

      好的,我之前忽略了这一点。在这里解释我的问题让我明白了:

      FastCGI 可以使用单个持久进程来处理其生命周期内的许多请求,而不是为每个请求创建一个新进程。 -- Wikipedia: FastCGI

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-09-18
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2017-03-25
        相关资源
        最近更新 更多