什么是 FastCGI

作者: 来源: 日期:2009-6-26

FastCGI 是什么?

FastCGI 是语言无关的、可伸缩架构的 CGI 开放扩展,其主要行为是将 CGI 解释器进程保持在内存中并因此获得较高的性能。众所周知,CGI 解释器的反复加载是 CGI 性能低下的主要原因,如果 CGI 解释器保持在内存中并接受 FastCGI 进程管理器调度,则可以提供良好的性能、伸缩性、Fail-Over(故障切换)特性等等。

FastCGI 的官方站点在 http://www.fastcgi.com/

FastCGI 工作原理

  1. Web Server 启动时载入 FastCGI 进程管理器(IIS ISAPI 或 Apache Module);
  2. FastCGI 进程管理器自身初始化,启动多个 CGI 解释器进程 (在任务管理器中可见多个 php-cgi.exe)并等待来自 Web Server 的连接。
  3. 当客户端请求到达 Web Server 时,FastCGI 进程管理器选择并连接到一个 CGI 解释器。Web server 将 CGI 环境变量和标准输入发送到 FastCGI 子进程 php-cgi.exe。
  4. FastCGI 子进程完成处理后将标准输出和错误信息从同一连接返回 Web Server。当 FastCGI 子进程关闭连接时,请求便告处理完成。FastCGI 子进程接着等待并处理来自 FastCGI 进程管理器(运行在 WebServer 中)的下一个连接。 在正常的 CGI 模式中,php-cgi.exe 在此便退出了。

在上述情况中,你可以想象 CGI 通常有多慢。每一个 Web 请求 PHP 都必须重新解析 php.ini、重新载入全部 dll 扩展并重初始化全部数据结构。使用 FastCGI,所有这些都只在进程启动时发生一次。一个额外的好处是,持续数据库连接(Persistent database connection)可以工作。

为什么要使用 FastCGI,而不是多线程 CGI 解释器?

这可能出于多方面的考虑,例如:

  1. 1、你无论如何也不能在 Windows 平台上稳定的使用多线程 CGI 解释器,无论是 IIS ISAPI 方式还是 APACHE Module 方式,它们总是运行一段时间就崩溃了。奇怪么?但是确实存在这样的情况!
    当然,也有很多时候你能够稳定的使用多线程 CGI 解释器,但是,你有可能发现网页有时候会出现错误,无论如何也找不到原因,而换用 FastCGI 方式时这种错误的概率会大大的降低。我也不清楚这是为什么,我想独立地址空间的 CGI 解释器可能终究比共享地址空间的形式来得稳定一点点。
  2. 性能!性能?可能么,难道 FastCGI 比多线程 CGI 解释器更快?但有时候确实是这样,只有测试一下你的网站,才能最后下结论。原因嘛,我觉得很难讲,但有资料说在 Zend WinEnabler 的时代,Zend 原来也是建议在 Windows 平台下使用 FastCGI 而不是 IIS ISAPI 或 Apache Module,不过现在 Zend 已经不做这个产品了。

不使用 FastCGI 的理由

  1. 多进程比多线程消耗更多的服务器内存,php-cgi.exe 解释器每进程消耗 7 至 25 兆内存,将这个数字乘以 50 或 100 试试。
  2. 性能。确实有时候多线程 CGI 解释器更快,呵呵,而且有时候,它也很稳定。
  3. CGI?听起来就很土,呵呵

(本文摘自 FastCGI 不完全高级指南(PHP版,Windows平台)

你前面那位网友看了:解决列高度自适应的五种方法!

▲▲▲嘿,欢迎转载传播本站原创文章,尽量保留来源噢。▲▲▲

文章评论
标题:必填
内容: