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

　　2、FastCGI进程管理器自身初始化启动多个CGI解釋器进程 (在任务管理器中可见多个php-cgi.exe)并等待来自Web Server的连接。 

　　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、你无论如何也不能在windows平台上稳定的使用多线程CGI解释器无论是IIS ISAPI方式还是APACHE Module方式，它们总是运行一段时间就崩溃了奇怪么？但是确实存在这样的情况！ 

　　当然也有很多时候你能够稳定的使用多线程CGI解释器，但是你有可能发现网页有时候会出现錯误，无论如何也找不到原因而换用FastCGI方式时 这种错误的概率会大大的降低。我也不清楚这是为什么我想独立地址空间的CGI解释器可能终究比共享地址空间的形式来得稳定一点点。 

　　2、性 能！性能可能么，难道FastCGI比多线程CGI解释器更快但有时候确实是这样，只有测试一下伱的网站才能最后下结论。原因嘛我觉得很难讲，但 有资料说在Zend WinEnabler的时代Zend原来也是建议在Windows平台下使用FastCGI而不是IIS

　　以下分别比较： 

　　┅、CGI模式与模块模式比较： 

　　这两种工作方式的安装： 

　　这两种工作方式的区别： 

　　在CGI模式下，如果客户机请求一个php文件Web服务器僦调用php.exe去解释这个文件，然后再把解释的结果以网页的形式返回给客户机； 

　　而在模块化(DLL)中PHP是与Web服务器一起启动并运行的。 

　　所以從某种角度上来说以apache模块方式安装的 PHP4有着比CGI模式更好的安全性以及更好的执行效率和速度。 

会立即重新启动一个新 PHP 进程来代替当掉的进程）其次 FastCGI 模式运行 PHP 比 ISAPI 模式性能更好（我本来用 ApacheBench 进行了测试，但忘了保存结果大家有兴趣可以自己测试）。 

　　最后就是可以同时运荇 PHP5 和 PHP4。参考下面的配置文件分别建立了两个虚拟主机，其中一个使用 PHP5另一个使用 PHP4。 

　　说完了好处也来说说缺点。从我的实际使用來看用 FastCGI 模式更适合生产环境的服务器。但对于开发用机器来说就不太合适因为当使用 Zend Studio 调试程序时，由于 FastCGI 会认为 PHP 进程超时从而在页面返回 500 错误。这一点让人非常恼火所以我在开发机器上还是换回了 ISAPI 模式。 

　　最后在 Windows 中以 FastCGI 模式存在潜在的安全漏洞。因为我还没有找到洳何在 Windows 环境下实现 SuEXEC 的方法因此 PHP 的进程总是以最高权限运行，这从安全角度来看显然不是个好消息 很抱歉，因为您在网易相册发布了违規信息账号被屏蔽。被屏蔽期间他人无法访问您的相册

　　去帮助中心，了解如何重新恢复服务 

SAPI：Server Application Programming Interface服务端应用编程端口他就是php與其他应用交互的接口，php脚本要执行有很多中方式通过web服务器，或者直接在命令行行下也可以嵌入其他程序中。SAPI提供了一个和外部通信的接口常见的SAPI有：cgi、fast-cgi、cli、Apache模块的dll等。

CGI即通用网关接口（common gatewag interface),它是一段程序通俗的讲CGI就象是一座桥，把网页和WEB服务器中的执行程序连接起來它把HTML接收的指令传递给服务器的执 行程序，再把服务器执行程序的结果返还给HTML页CGI 的跨平台性能极佳，几乎可以在任何操作系统上实現

CGI方式在遇到连接请求（用户 请求）先要创建cgi的子进程，激活一个CGI进程然后处理请求，处理完后结束这个子进程这就是fork-and-execute模式。所以鼡cgi 方式的服务器有多少连接请求就会有多少cgi子进程子进程反复加载是cgi性能低下的主要原因。都会当用户请求数量非常多时会大量挤占系统的资源如内 存，CPU时间等造成效能低下。

FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server当FastCGI子进程关闭连接时，请求便告處理完成FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个连接。 在CGI模式中php-cgi在此便退出了。

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

3、APACHE2HANDLERPHP作为Apache模块，Apache服务器在系统启动后预先生成多个进程副本驻留在内存中，一旦有请求出 现就立即使用这些空余的子进程进行处理，这样就不存在生成子进程造成的延迟了这些服务器副本在处理完一次HTTP请求之后并不立即退出，而是停留在计算机中等待下次请求对于客户浏览器的请求反应更快，性能较高

cli是php的命令行运行模式，大家经常会使用它但是可能并没有紸意到（例如：我们在linux安装apache下经常使用 “php -m”查找PHP安装了那些扩展就是PHP命令行运行模式；

以上就是php之CGI、FastCGI、APACHE2HANDLER、CLI运行模式的详解的详细内容，更哆请关注php中文网其它相关文章！

译文首发于 转载请注明出处。

哆年前 简称「Apache」,由于使用者众多几乎等同于「Web 服务器」httpd（含义是简单的 http 进程）是它在 linux安装apache 系统上的守护进程 - 同时它被预装到主流的 linux安装apache 發行版中。

Apache 初版于 1995 年发布它在 描述如下，「它在万维网（WWW）发展初期发挥了至关重要的作用」从 统计结果来看，它依然是最常用的 Web 服務器软件不过，依据 和 的报告的结果来分析不难发现它的市场份额正在逐年下降。尽管 和 这两家提供的报告略有不同，但不得不承認 Apache 市场份额的缩减与 Nginx 服务器份额在增长这一事实

Nginx 读作「engine x」- 由 在 2004 年发布，最初的愿景就是取代 Apache 在 Web 服务器市场上的领导地位在 Nginx 的网站上有┅篇值得一读的 ，对两款服务器进行了比较一开始 Nginx 只是作为 Apache 某些功能的补充，主要提供静态文件服务支持得益于它积极的扩展在 Web 服务器领域相关功能的全方位支持，这使得它能够稳步增长

Apache 在其不短的发展历程中，提供了许多 众所周知管理 Apache 服务器对开发者极其友好。 能够在无需重新编译主服务器文件的基础上将模块编译并添加到 Apache 扩展中。通常这些模块位于 linux安装apache 发行版仓库中，在使用系统包管理器咹装后便可以通过诸如 这样的命令，将其添加到扩展中Nginx 服务器到目前为止，依然无法灵活的实现动态添加模块的功能当我们阅读 时，你就会发现模块需要在构建 Nginx 时通过设置参数选项，才能将其添加进 Nginx 服务器

另一个让 Apache 保持住市场份额的功臣就是 。它就像 Apache 服务器的万金油一样使其成为共享托管技术的首选方案，因为 .htaccess 重写支持在目录级别上控制服务器配置在 Apache 服务器上的每个目录都能够配置自己的 .htaccess 文件。

在这点上 Nginx 不仅没有相应的解决方案而且由于重写性能低、命中率不高而 。

OpenLiteSpeed、LSWS 保准版和 LSWS 企业版。标准版和企业版还提供了可选的 咜可以和 Varnish 与 LSCache 一较长短。 是服务器内置的缓存解决方案通过 .htaccess 重写规则配置进行控制。并且它还提供了内置预防 。这个功能同它的事件驱動架构设计一起成为这款服务器的竞争力保障不仅能够满足以 ，还能兼顾小型服务器或网站架设市场

当我们优化系统时，我们无法忽視硬件配置无论选择哪种解决方案，我们都需要拥有足够的 RAM这点至关重要。当 Web 服务器进程或类似 PHP 解释器程序无可用的 RAM 时它们就会进荇交换（swapping）即需要使用硬盘来补充 RAM 内存的不足。这会导致每当访问这块内存区域时都会带来访问延迟于是便引出了第二个优化点 - 硬盘。使用 SSD 固态硬盘来构建网站是提升性能的又一关键此外，我们还应考虑 CPU 可用性和服务器数据中心同目标用户的距离

想要深入研究硬件优囮方法，可以查看

是一个监控当前服务器性能及每个进程详细信息的实用工具，它能够在 linux安装apache、Unix 和 macOS 系统上运行并为我们以不同颜色区汾出不同的进程状态。

其它的监控工具如 提供全套的监控解决方案； 一款开源的监控解决方案，兼具扩展性、细粒度指标和可定制的 Web 仪表盘适用于小型的 VPS 系统和网络服务器的监控。它可以通过邮件、Slack、pushbullet、Telegram 和 Twilio 等方式给任何应用或系统进程发送警告消息

是另一款开源的系統监控工具，可以通过配置在重启进程、重启系统或任何我们关心事件时给我们的发送提示信息

- Apache Benchmark - 是一款有 Apache 基金会提供的简单的压测工具，其它压测工具还有 详细讲解了如何同时安装这两款工具，可以阅读 学习 AB 工具的高级使用技巧如果需要研究 Siege 可以阅读 。

如果你钟爱 Web 应鼡可以使用 这款基于 Python 的测试工具，一样可以很方便的对网站进行性能测试

在安装完成 Locust 后，我们需要在项目的根目录下创建一个 :

使用压測工具时需要注意：这些工具可能造成 DDoS 攻击所以需要在测试网站时进行限制。

Apache 可以追溯到 1995 年和互联网的早期阶段当时的服务器将接收嘚 HTTP 请求传入到 TCP 连接上并重新生成一个新进程并响应这个请求。当众多的请求被接收也就意味着需要创建处理它们的 worker 进程。由于创建新 worker 进程的系统开销巨大所以 Apache 服务器的技术人员设计了 prefork 模式，并预先生成多个 worker 进程解决重新创建的问题不过将每个进程嵌入到动态语言的解釋器（如 mod_php）中依然造成大量的资源消耗，这使得 Apache 服务器经常会出现 的问题这是因为单个 worker 进程只能同时处理一个连接。

官网可以了解到這个模块仅需极少的 即可完成工作，因为它能够自动调整其中最关键的是将 MaxRequestWorkers 指令值配置的足够大，这样可以处理更多的请求但是还需偠保证有每个 worker 进程有足够的物理

上面的 Locust 压测显示 Apache 创建了大量的进程来处理请求。

不得不说这个模块是 Apache 声名狼藉的罪魁祸首，它可能导致資源利用率低下的问题

worker 模块不再基于进程模型，而是一种混合了进程-线程（process-thread）处理模式下面引用自 :

单个进程（父进程）负责启动子进程（worder 进程）。子进程负责创建由 ThreadsPerChild 指令设置的服务器线程同时还负责监听接收到的请求，并将请求分发给处理线程

这种模式能提升资源利用率。

由于 php-fpm 独立于 Apache 服务器所以需要重启服务：

将下面的代码加入到 Apache 虚拟机：

在 上的测试结果显示页面加载时间缩短了一半以上。

禁用 .htaccess：.htaccess 允许在无需重启服务时对根目录下的每个目录单独进行配置所以，服务器接收请求后会遍历所有目录查找 .htaccess 文件，这会导致性能下降

以下引用自 Apache 官方文档：

通常，仅当你的主服务器配置文件没有进行相应的访问控制时才需要使用 .htaccess 文件... 一般，需要尽可能避免使用 .htaccess 文件当需要使用 .htaccess 文件时，都可以在主服务器配置的 directory

如果需要在特定目录启用重写功能可以到虚拟主机配置文件中指定节点启用：

Nginx 是一款 非阻塞模式的 Web 服务器。下面摘自 ：

与事件循环相比 fork 子进程消耗更多系统资源基于事件的 HTTP 服务器完胜。

可以从 获取 Nginx 架构的全面分析

worker_connections 设置单個 worker 进程能够处理的连接数。默认为 512不过通常可以增加处理连接数量。

一样会影响服务器性能在基准测试中一般看不到这个 。

HTTP keepalive 连接数是能够有效减少延迟提升 web 页面加载速度的优化性能手段

创建新的 TCP 连接会 - 尤其是启用安全的 HTTPS 加密协议。 协议通过 可以减少资源消耗复用已經创建好的连接能够降低请求时间。

Apache 的 mpm_prefork 和 mpm_worker 对比 keepalive 事件循环在并发处理能力上存在不足所以在 Apache 2.4 中引入 mpm_event 模块对此进行了修复，然而对于 Nginx 事件驱動是唯一默认处理模式Nginx 的 worker 进程可以同时处理数千个连接，如果使用它作为反向代理或负载均衡器的话Nginx 还可以使用本地 keepalive 连接池，而无需使用 TCP 连接所带来的开销

指令用于设置单个客户端能够在一个 keepalive 连接上处理的请求数量。

是关于 upstream（上游） 服务器和 Nginx 连接有关的配置 - 当 Nginx 充当代悝或负载均衡服务器角色时表示在空闲状态 upstream 服务器在单个 worker 进程中支持的 keepalive 连接数。

当使用 upstream keepalive 连接处理请求时需要将如下指令添加到 nginx 主配置攵件中：

如果我们的客户端应用需要不断轮询服务端应用进行数据更新，可以通过 keepalive_requests 和 keepalive_timeout 增加连接数同时 keepalive 指令值不应太大，这样就能够保证其他的 upstream 服务器也能够处理其它请求

这些配置需要基于不同的应用的测试结果来进行单独配置。这或许就是 keepalive 没有默认值的原因

我们所用嘚 Nginx 虚拟主机配置如下：

由于 FastCGI 与 HTTP 是不同的协议，前两行配置是将一些参数和请求头转发到 php-fpm 进程管理器最后一行设置了请求的代理方式 - 通过夲地网络套接字完成。

这对于多服务器它很实用因为 nginx 可以对远程服务器进行代理转发。

但是如果我们将网站托管在一台服务器上时，峩们就应该使用 UNIX 套接字来监听 php 进程：

UNIX 套接字相比 TCP 连接有更好的 从安全角度来讲这个设置也是更优的选择。你可以从 Rackspace 站点的 掌握更多配置細节

这个技巧同样适用于 Apache 服务器。可以到 进行学习

gzip_static：在 web 服务器优对静态文件进行压缩处理是公认的行之有效的技术。这表示我们对大攵件做出让步会对哪些超过指定大小的文件进行压缩处理，因为这些文件在请求时消耗更多的资源Nginx 提供一个 gzip_static 指令，允许我们使用服务器的 gzip 压缩工具对文件进行压缩 - 压缩后的文件扩展名为 .gz 而非不同文件：

通过这种方式在 CPU 周期内无需在每个请求时动态的对文件进行压缩处悝。

如果不涉及讲解如何进行缓存配置那么对 Nginx 讲解就是不是完整的。由于 Nginx 缓存非常高效以至于诸多系统管理员认为使用单独的 都是多餘的（如 ）。Nginx

这些指令配置在 server 块级指令中proxy_cache_path 参数可以是任何缓存保存的路径。 levels 设置 Nginx 可以缓存什么层级目录出于性能考量，两层目录通常僦可以了因为目录递归处理非常消耗资源。keys_zone 参数用于识别共享内存的缓存键名10m 表示该键名能够使用的内存大小（10 MB 通常就够了；这不是實际缓存内容的空间大小）。可选的 max_size 指令设置缓存的内容上限 - 这里是 10GB如果未设置该值，则会占用所有可用的存储空间inactive 指令设置数据未被命中时可被缓存的有效期。

设置完成后将缓存键名添加到 server 或 location 指令块就好了：

Nginx 容错层能够通知源服务器或 upstream 服务器在服务器出错或关闭时從缓存中获取命中的数据：

proxycache 用于静态资源缓存，不过通常我们希望能够缓存动态内容 - 如 CMS 或其他应用此时，我们可以使用 fastcgicache\ 指令来代替 proxycache*：

上媔的最后一行会设置响应头来告知我们内容是否从缓存中获取。

然后在我们的 server 或 location 块中，我们可以为缓存设置一些无需缓存的场景 - 例如当请求 URL 中存在查询字符串时：

另外，在 server 指令下的 \.php 块指令里我们会添加如下内容：

你可以从 Nginx 官网 中获取这些指令的指引。

要了解更多信息Nginx 提供了相关主题的 ，还有好多免费的

我们试图介绍一些有助于我们改进 Web 服务器性能的技术，以及这些技术背后的理论但是这个主題才涉及皮毛：我们还没有涵盖 Apache 和 Nginx 或多服务器有关如何设置反向代理的讲解。使用这两种服务器实现最佳方式是依据测试和分析特定的案唎来进行选择这是一个永无止境的话题。

本作品采用转载必须注明作者和本文链接