分类: LINUX
2009-05-15 11:35:17
LAMP 系统性能调优,第 2 部分: 优化 Apache 和 PHP是什么降低了 Apache 的速度,如何使 PHP 发挥最大效力 |
级别: 中级 Sean A. Walberg (), 高级网络工程师 2007 年 6 月 07 日 如今,使用 LAMP(Linux®、Apache、MySQL 和 PHP/Perl)架构的应用程序不断被开发和部署。但是,服务器管理员常常对应用程序本身几乎没有控制能力,因为应用程序是别人编写的。这份 共三部分的系列文章 将讨论许多服务器配置问题,这些配置会影响应用程序的性能。第二篇文章重点讨论可为优化 Apache 和 PHP 而采取的措施。 Linux、 Apache、MySQL 和 PHP(或 Perl)是许多 Web 应用程序的 LAMP 架构的基础。有很多基于 LAMP 组件的开源软件包可用于解决各种各样的问题。随着应用程序负载的增加,底层基础设施的瓶颈也会越来越明显,其表现形式就是响应用户请求的速度变慢。 上一篇文章 展示了调优 Linux 系统的方法,还介绍了 LAMP 和性能度量的基础知识。本文重点关注 Web 服务器组件:Apache 和 PHP。 Apache 是一种高度可配置的软件。它具有大量特性,但每一种都代价高昂。从某种程度上来说,调优 Apache 来说就是以恰当的方式分配资源,还涉及到将配置简化为仅包含必要内容。 Apache 是模块化的,因为可以轻松添加和移除特性。在 Apache 的核心,多处理模块(Multi-Processing Module,MPM)提供了这种模块化功能性 —— 管理网络连接、调度请求。MPM 使您能够使用线程,甚至能够将 Apache 迁移到另外一个操作系统。 每次只能有一个 MPM 是活动的,必须使用 每个请求使用一个进程的传统模型称为 prefork。较新的线程化模型称为 worker,它使用多个进程,每个进程又有多个线程,这样就能以较低的开销获得更好的性能。最新的 event MPM 是一种实验性的模型,为不同的任务使用单独的线程池。要确定当前使用的是哪种 MPM,可执行 选 择使用何种 MPM 取决于许多因素。在 event MPM 脱离实验状态之前,不应考虑这种模型,而是在使用线程和不使用线程之间作出选择。表面上看来,如果所有底层模块(包括 PHP 使用的所有库)都是线程安全的,线程要优于分叉(forking)。而 Prefork 是较为安全的选择;如果选择了 worker,则应该谨慎测试。性能收益还取决于您的发布版所附带的库及硬件。 无论选择了哪种 MPM,都必须恰当地配置它。一般而言,配置 MPM 包括告知 Apache 怎样去控制有多少 worker 正在运行,它们是线程还是进程。prefork MPM 的重要配置选项如清单 1 所示。
prefork 模型会为每个请求创建一个新进程。多余的进程保持空闲,以处理传入的请求,这缩短了启动延迟。只要 Web 服务器出现,预先完成的配置就会立即启动 50 个进程,并尽力保持 10 到 20 个空闲服务器运行。进程数的硬性限制由 配置线程化 MPM 与之类似,不同之处只是必须确定使用多少线程和进程。Apache 文档解释了所有必要的参数和计算。 要经过几次尝试和出错之后才能选好要使用的值。最重要的值是 如果 根据服务器的角色调优要启动和保持空闲的服务器数量。如果服务器仅运行 Apache,那么可以使用适中的值,如 清单 1 所示,因为这样就能充分利用机器。如果系统中还有其他数据库或服务器,那么就应该限制运行中的空闲服务器的数量。 Apache 处理的每个请求都要履行一套复杂的规则,这些规则指明了 Web 服务器必须遵循的约束或特殊指令。对文件夹的访问可能按 IP 地址约束为某个特定文件夹,也可配置用户名和密码。这些选项还包含处理特定文件,例如,如果提供了一个目录列表,该如何处理的文件,或输出结果是否应压 缩。 这些配置以 httpd.conf 中容器的形式出现,例如
在清单 2 中,位于一对
最后这个场景正是导致两方面关注的原因所在。第一个方面与性能有关。如果禁用了 至 此,有安全意识的读者应该有了警惕的感觉。安全性永远是功能性与风险之间的权衡。在我们的例子中,功能性是速度,而风险是允许对系统上的文件进行未经授权 的访问。缓解风险的措施之一是 LAMP 应用服务器通常专注于一种具体功能,用户无法创建危险的符号连接。如果有必要启用符号连接,那么可以将其约束在文件系统的特定区域,如清单 3 所示。
在清单 3 中,一个用户的主目录中的任何 public_html 目录及其所有子目录都移除了 如您所见,通过主服务器配置,可为每个目录单独配置选项。用户可以自行重写这种服务器配置(如果管理员通过 即便 最简单的解决方案
是不允许重写,这能消除 Apache 检查 .htaccess 的需求。之后的任何特殊配置都将直接放在 httpd.conf 中。清单 4
显示为对一个用户的项目目录进行密码检查向 httpd.conf 增加的代码,而不是将其放入一个 .htaccess 文件并依赖于
如果配置转移到 httpd.conf 中,且 有时不可能彻底消除 .htaccess 文件的使用。例如,在清单 5 中,一个选项被约束到文件系统的特定部分,重写也可以是有作用域的。
实现清单 5 之后,Apache 会在父目录中查找 .htaccess 文件,但会在 public_html 目录处停止,因为文件系统的其余部分禁用了此功能。例如,如果请求的是一个映射到 /home/user/public_html/project/notes.html 的文件,那么仅有 public_html 和 project 目录被搜索。 关于每目录单独配置的最后一个提示就是:要按顺序依次进行。任何介绍 Apache 调优的的文章都会告诉您,应通过 一 个客户机连接到 Web 服务器时,允许客户机通过同一个 TCP 连接发出多个请求,这减少了与多个连接相关的延迟。在一个 Web 页面引用了多幅图片时,这就很有用:客户机可以通过一个连接先请求页面,再请求所有图片。其缺点在于服务器上的 worker 进程必须等待客户机要关闭的会话,之后才能转到下一个请求。 Apache 使您能够配置如何处理持久连接(称为 keepalives)。httpd.conf 全局级的 持久连接的处理并非 “一刀切” 式的配置。对于某些 Web 站点,禁用 keepalives 更合适( Web 服务器能够在将输出发回给客户机之前压缩它。这将使通过 Internet 发送的页面更小,代价是 Web 服务器上的 CPU 周期。对于那些负担得起 CPU 开销的服务器来说,这是提高页面下载速度的好办法 —— 页面压缩后大小变为原来的三分之一这种事情并不罕见。 图片通常已经是压缩过的,因此压缩应仅限于文本输出。Apache 通过 PHP 是运行应用程序代码的引擎。应该仅安装计划使用的那些模块,并配置您的 Web 服务器,使之仅为脚本文件(通常是以 .php 结尾的那些文件)使用 PHP,而非所有静态文件。 请求一个 PHP 脚本时,PHP 会读取该脚本,并将其编译为 Zend 操作码,这是要执行的代码的一种二进制表示形式。随后,此操作码由 PHP 执行并丢弃。操作码缓存将保存这个编译后的操作码,并在下一次调用该页面时重用它。这会节省很多时间。有多种缓存可用,我比较常用的是 eAccelerator。 要安装 eAccelerator,您的计算机上需要有 PHP 开发库。由于不同的 Linux 发布版存放文件的位置不同,所以最好直接从 eAccelerator 的 Web 站点获得安装说明(参见 参考资料 部分获得链接)。您的发布版也有可能已经包含了一个操作码缓存,只需安装即可。 无论如何在系统上安装 eAccelerator,都有一些配置选项需要注意。配置文件通常是 /etc/php.d/eaccelerator.ini。 如果共享内存的分配超出极限,eAccelerator 必须将旧脚本从内存中清除。默认情况下,这是被禁用的; 另一种流行的 eAccelerator 替代工具是 Alternative PHP Cache(APC)。Zend 的厂商也提供了一种商业操作码缓存,包括一个进一步提高效率的优化器。 PHP 的配置是在 php.ini 中完成的。四个重要的设置控制 PHP 可使用多少系统资源,如表 1 所列。
具体数字主要取决于您的应用程序。如果要从用户处接收大文件,那么 PHP 可执行的日志记录数是可配置的。在生产环境中,禁用除最重要的日志以外的一切日志记录能够减少磁盘写操作。如果需要使用日志来排除问题,那么可以按需启用日志记录。
本 文重点探讨 Web 服务器的调优,包括 Apache 和 PHP。对于 Apache,总体的想法是消除 Web 服务器必须执行的多余检查,例如处理 .htaccess 文件。还必须调优所用的多处理模块,以便在使用的系统资源和可供传入请求使用的空闲 worker 之间找到平衡。对于 PHP,最好的事情就是安装一个操作码缓存。密切注意几个资源设置也能确保脚本不会浪费系统资源,不会减慢系统处理其他任务的速度。 本系列的下一篇也是最后一篇文章将介绍 MySQL 数据库的调优。请继续关注! |