PHP CGI FastCGI php-fpm HHVM

web服务器接受到浏览器的请求时，若是是静态资源如 html 文件就直接将其返回给浏览器；若是是 php、asp 这样的动态资源，服务器本身不能处理，就要外包给别人处理，具体实现就须要CGI （common gateway interface）约定，cgi能够理解为一种协议or一类处理程序，能够用 vb，c，php， python 实现。

WEB 与 CGI 交互

CGI（Common Gateway Interface）是1993年由美国国家超级电脑应用中心（NCSA）为 NCSA HTTPd Web 服务器开发的。这个 Web 服务器使用了 UNIX shell 环境变量 来保存从 Web 服务器传递出去的参数，而后生成一个运行 CGI 的独立进程。CGI的第一个实现是 Perl 写的，可是 CGI 有以下问题：

• 效率低下：每个链接 fork 一个进程处理。
• 功能十分有限：CGI只能收到一个请求，输出一个响应。

因此就有了Apache的mod_php，FastCGI（Fast Common Gateway Interface）

FastCGI使用进程/线程池来处理一连串的请求。这些进程/线程由FastCGI服务器管理，而不是Web服务器。 当进来一个请求时，Web服务器把环境变量和这个页面请求经过一个Socket长链接传递给FastCGI进程。因此FastCGI有以下的优势：

• 性能：经过进程/线程池规避了CGI开辟新的进程的开销。
• 兼容：很是容易改造现有CGI标准的程序。
• 语言无关：FastCGI是一套标准，理论上讲只要能进行标准输出（stdout）的语言均可以做为FastCGI标准的Web后端。

Web Server隔离：FastCGI后端和Web Server运行在不一样的进程中，后端的任何故障不会致使Web Server挂掉。

专利：没有Apache mod_php之类的私有API的知识产权问题。

扩展：FastCGI后端和Web Server经过Socket进行通讯，二者能够分布式部署并方便进行横向扩展。

HHVM

HHVM 是 Facebook 开发的高性能 PHP 虚拟机，宣称比官方的快9倍。

在讨论 HHVM 实现原理前，咱们先设身处地想一想：假设你有个 PHP 写的网站遇到了性能问题，经分析后发现很大一部分资源就耗在 PHP 上，这时你会怎么优化 PHP 性能？

好比能够有如下几种方式：

• 方案1，迁移到性能更好的语言上，如 Java、C++、Go。
• 方案2，经过 RPC 将功能分离出来用其它语言实现，让 PHP 作更少的事情，好比 Twitter 就将大量业务逻辑放到了 Scala 中，前端的 Rails 只负责展示。
• 方案3，写 PHP 扩展，在性能瓶颈地方换 C/C++。
• 方案4，优化 PHP 的性能。

方案1几乎不可行，十年前 Joel 就拿 Netscape 的例子警告过，你将放弃是多年的经验积累，尤为是像 Facebook 这种业务逻辑复杂的产品，PHP 代码实在太多了，据称有2千万行（引用自 [PHP on the Metal with HHVM]），修改起来的成本恐怕比写个虚拟机还大，并且对于一个上千人的团队，从头开始学习也是不可接受的。

方案2是最保险的方案，能够逐步迁移，事实上 Facebook 也在朝这方面努力了，并且还开发了 Thrift 这样的 RPC 解决方案，Facebook 内部主要使用的另外一个语言是 C++，从早期的 Thrift 代码就能看出来，由于其它语言的实现都很简陋，无法在生产环境下使用。

目前在 Facebook 中据称 PHP:C++ 已经从 9:1 增长到 7:3 了，加上有 Andrei Alexandrescu 的存在，C++ 在 Facebook 中愈来愈流行，但这只能解决部分问题，毕竟 C++ 开发成本比 PHP 高得多，不适合用在常常修改的地方，并且太多 RPC 的调用也会严重影响性能。

方案3看起来美好，实际执行起来却很难，通常来讲性能瓶颈并不会很显著，大可能是不断累加的结果，加上 PHP 扩展开发成本高，这种方案通常只用在公共且变化不大的基础库上，因此这种方案解决不了多少问题。

能够看到，前面3个方案并不能很好地解决问题，因此 Facebook 其实没有选择的余地，只能去考虑 PHP 自己的优化了。

http://wuduoyi.com/note/hhvm/