早期的webserver只处理html等静态文件，但是随着技术的发展，出现了像php等动态语言。
webserver处理不了了，怎么办呢？那就交给php解释器来处理吧！
交给php解释器处理很好，但是，php解释器如何与webserver进行通信呢？
为了解决不同的语言解释器(如php、python解释器)与webserver的通信，于是出现了cgi协议。只要你按照cgi协议去编写程序，就能实现语言解释器与webwerver的通信。如php-cgi程序。
FastCGI的改进
有了cgi协议，解决了php解释器与webserver通信的问题，webserver终于可以处理动态语言了。但是，webserver每收到一个请求，都会去fork一个cgi进程，请求结束再kill掉这个进程。这样有10000个请求，就需要fork、kill php-cgi进程10000次。
有没有发现很浪费资源？
于是，出现了cgi的改良版本，fast-cgi。fast-cgi每次处理完请求后，不会kill掉这个进程，而是保留这个进程，使这个进程可以一次处理多个请求。这样每次就不用重新fork一个进程了，大大提高了效率。
PHP-FPM是什么
php-fpm即php-Fastcgi Process Manager.
php-fpm是 FastCGI 的实现，并提供了进程管理的功能。
进程包含 master 进程和 worker 进程两种进程。
master 进程只有一个，负责监听端口，接收来自 Web Server 的请求，而 worker 进程则一般有多个(具体数量根据实际需要配置)，每个进程内部都嵌入了一个 PHP 解释器，是 PHP 代码真正执行的地方。
FastCGI是什么？
FastCGI是语言无关的、可伸缩架构的CGI开放扩展，其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。众所周知，CGI解释器的反复加载是CGI性能低下的主要原因，如果CGI解释器保持在内存中并接受FastCGI进程管理器调度，则可以提供良好的性能、伸缩性、Fail-Over特性等等。
FastCGI的官方站点在http://www.fastcgi.com
FastCGI的工作原理是
1、Web Server 启动时载入FastCGI进程管理器（IIS ISAPI或Apache Module,nginx 下 fastcgi 与服务器是分离的，fastcgi 可有 lighttpd 下的spawan-cgi或者 php-fpm 来管理））;
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)可以工作。
总结
nginx与php-fpm的结合，完整的流程是这样的：
为什么要使用FastCGI，而不是多线程CGI解释器？
这可能出于多方面的考虑，例如：
1、你无论如何也不能在windows平台上稳定的使用多线程CGI解释器，无论是IIS ISAPI方式还是APACHE Module方式，它们总是运行一段时间就崩溃了。奇怪么？但是确实存在这样的情况！当然，也有很多时候你能够稳定的使用多线程CGI解释器，但是，你有可能发现网页有时候会出现错误，无论如何也找不到原因，而换用FastCGI方式时这种错误的概率会大大的降低。我也不清楚这是为什么，我想独立地址空间的CGI解释器可能终究比共享地址空间的形式来得稳定一点点。
2、性能！性能？可能么，难道FastCGI比多线程CGI解释器更快？但有时候确实是这样，只有测试一下你的网站，才能最后下结论。原因嘛，我觉得很难讲，但有资料说在Zend WinEnabler的时代，Zend原来也是建议在Windows平台下使用FastCGI而不是IIS ISAPI或Apache Module，不过现在Zend已经不做这个产品了。
FastCGI的技术原理
如果想了解FastCGI的技术原理就要了解何为”短生存期应用程序”,何为”长生存期应用程序”。
先从CGI技术开刀，以下是CGI技术的理论：每次当客户请求一个CGI的时候，Web服务器就请求操作系统生成一个新的CGI进程。当CGI满足要求后，服务器就杀死这个进程。服务器对客户端的每个请求都要重复这样的过程。
而FastCGI技术的理论为：FastCGI程序一旦产生后，他可以持续工作,足够满足客户的请求直到被明确的终止。如果你希望通过协同处理来提高程序的性能，你可以请求Web服务器运行多个FastCGI 应用程序的副本。
CGI就是所谓的短生存期应用程序，FastCGI就是所谓的长生存期应用程序。
由于FastCGI程序并不需要不断的产生新进程，可以大大降低服务器的压力。并且产生较高的应用效率。
自今，较为流行的Java语言Servlet技术在设计上是以参考FastCGI的技术运行所设计。
FastCGI的特点
1. 打破传统页面处理技术
传统的页面处理技术，程序必须与Web服务器或Application服务器处于同一台服务器中。这种历史已经早N年被FastCGI技术所打破， FastCGI技术的应用程序可以被安装在服务器群中的任何一台服务器，而通过TCP/IP协议与Web服务器通讯，这样做既适合开发大型分布式Web 群，也适合高效数据库控制。
2. 明确的请求模式
CGI技术没有一个明确的角色，在FastCGI程序中，程序被赋予明确的角色（响应器角色、认证器角色、过滤器角色）。
3. 合理的程序结构
起初，真的很讨厌FastCGI应用程序的结构要求。没关系，您经过一段时间编写后就会喜欢这种结构，只有这种完全规范的结构才能让您的程序更有效率。