LAMP 系统性能调优--理解 LAMP 架构（1）

look_w

Linux、Apache、MySQL 和 PHP（或 Perl）是许多 Web 应用程序的基础 —— 从 to-do 列表到 blog，再到电子商务站点。WordPress 和 Pligg 是两个支持大容量 Web 站点的常用软件包。这种架构简称为 LAMP。几乎每个 Linux 发布版都包含 Apache、MySQL、PHP 和 Perl，所以安装 LAMP 软件是非常容易的。
安装的简便性使人误以为这些软件会自行顺利地运行，但是实际情况并非如此。最终，应用程序的负载会超出后端服务器自带设置的处理能力，应用程序的性能会降低。LAMP 安装需要不断监控、调优和评估。
系统调优对于不同的人有不同的含义。本系列主要关注 LAMP 组件（Linux、Apache、MySQL 和 PHP）的调优。对应用程序本身进行调优是另一个复杂的问题。应用程序和后端服务器之间存在一种共生关系：未能适当调优的服务器甚至会使最好的应用程序在负载之下崩溃，而借助充分的调优，完全可以避免编写得很糟糕的应用程序使服务器缓慢如牛。幸运的是，正确的系统调优和监视可以指出应用程序中的问题。
LAMP 架构对任何系统进行调优的第一步都是了解它的工作原理。按照最简单的形式，基于 LAMP 的应用程序是用 PHP 这样的脚本语言编写的，它们作为 Linux 主机上运行的 Apache Web 服务器的一部分运行。
PHP 应用程序通过请求的 URL、所有表单数据和已捕获的任意会话信息从客户机获得信息，从而确定应该执行什么操作。如有必要，服务器会从 MySQL 数据库（也在 Linux 上运行）获得信息，将这些信息与一些 Hypertext Markup Language（HTML）模板组合在一起，并将结果返回给客户机。当用户在应用程序中导航时，这个过程重复进行；当多个用户访问系统时，这个过程会并发进行。但是，数据流不是单向的，因为可以用来自用户的信息更新数据库，包括会话数据、统计数据（包括投票）和用户提交的内容（比如评论或站点更新）。除了动态元素之外，还有静态元素，比如图像、JavaScript 代码和层叠样式表（CSS）。
LAMP 的变体LAMP 最初是指 Linux、Apache、MySQL 和 PHP（或 Perl）。但是，如果管理员不擅长 Linux，那么可以在 Microsoft® Windows® 上运行 Apache、MySQL 和 PHP，这并非一种少见的情况。同样，也可以将 Apache 换成别的系统，比如 lighttpd，产生的仍然是 LAMP 风格的系统，但是首字母缩写不再是 LAMP 了。也可以改用另一种开放源码数据库（比如 PostgreSQL 或 SQLite）、商业数据库（比如 IBM® DB2®）或者免费的商业引擎（比如 IBM DB2 Express-C）。
本文主要关注传统的 LAMP 架构，因为这种架构是最常见的，而且它的组件都是开放源码的。

在研究 LAMP 系统中的请求流之后，就来看看可能出现性能瓶颈的地方。数据库提供许多动态信息，所以数据库对查询的响应延迟都会反映在客户机中。Web 服务器必须能够快速地执行脚本，还要能够处理多个并发请求。最后，底层操作系统必须处于良好的状态才能支持应用程序。通过网络在不同服务器之间共享文件的其他设置也可能成为瓶颈。
度量性能持续地对性能进行度量在两个方面有帮助。首先，度量可以帮助了解性能趋势，包括好坏两方面的趋势。作为一个简单的方法，查看一下 Web 服务器上的中央处理单元（CPU）使用率，就可以了解 CPU 是否负载过重。同样，查看过去使用的总带宽并推断未来的变化，可以帮助判断什么时候需要进行网络升级。这些度量最好与其他度量和观测结合考虑。例如，当用户抱怨应用程序太慢时，可以检查磁盘操作是否达到了最大容量。
性能度量的第二个用途是，判断调优是对系统性能有帮助，还是使它更糟糕了。方法是比较修改之前和之后的度量结果。但是，为了进行有效的比较，每次应该只修改一个设置，然后对适当的指标进行比较以判断修改的效果。每次只修改一个设置的原因应该是很明显的：同时做出的两个修改很可能会相互影响。选择用来进行比较的指标比较微妙。
选择的指标必须能够反映应用程序用户感觉到的响应。如果一项修改的目标是减少数据库的内存占用量，那么取消各种缓冲区肯定会有帮助，但是这会牺牲查询速度和应用程序性能。所以，应该选择应用程序响应时间这样的指标，这会使调优向着正确的方向发展，而不仅仅是针对数据库内存使用量。
可以以许多方式度量应用程序响应时间。最简单的方法可能是使用 curl 命令，见清单 1。
清单 1. 使用 cURL 度量 Web 站点的响应时间

1 2 3

$ curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total}\     http://www.canada.com 0.081:0.272:0.779

清单 1 给出对一个流行的新闻站点执行 curl 命令的情况。输出通常是 HTML 代码，通过 -o 参数发送到 /dev/null。-s 参数去掉所有状态信息。-w 参数让 curl 写出表 1 列出的计时器的状态信息：
表 1. curl 使用的计时器计时器描述time_connect建立到服务器的 TCP 连接所用的时间time_starttransfer在发出请求之后，Web 服务器返回数据的第一个字节所用的时间time_total完成请求所用的时间
这些计时器都相对于事务的起始时间，甚至要先于 Domain Name Service（DNS）查询。因此，在发出请求之后，Web 服务器处理请求并开始发回数据所用的时间是 0.272 - 0.081 = 0.191 秒。客户机从服务器下载数据所用的时间是 0.779 - 0.272 = 0.507 秒。
通过观察 curl 数据及其随时间变化的趋势，可以很好地了解站点对用户的响应性。
当然，Web 站点不仅仅由页面组成。它还有图像、JavaScript 代码、CSS 和 cookie 要处理。curl 很适合了解单一元素的响应时间，但是有时候需要了解整个页面的装载速度。
用于 Firefox 浏览器的 Tamper Data 扩展（参见  一节中的链接）可以在日志中记录 Web 浏览器发出的每个请求，并显示每个请求所用的下载时间。使用这个扩展的方法是，选择 Tools > Tamper Data 来打开 Ongoing requests 窗口。装载要考察的页面，然后就会看到浏览器发出的每个请求的状态和装载每个元素所用的时间。图 1 给出装载 developerWorks 主页的结果。
图 1. 用于装载 developerWorks 主页的请求细目每一行描述一个元素的装载情况。显示的数据包括发出请求的时间、装载所用的时间、大小和结果。Duration 栏列出装载元素本身所用的时间，Total Duration 栏列出所有子元素所用的时间。在图 1 中，装载主要页面所用的时间是 516 毫秒（ms），但是装载所有东西并显示整个页面所用的时间是 5101 ms。
Tamper Data 扩展有一种有用的模式，将页面装载数据的输出绘制成图形。右击 Ongoing requests 窗口上半部分的任何地方，并选择 Graph all。图 2 显示图 1 中数据的图形化视图。
图 2. 用于装载 developerWorks 主页的请求的图形化视图在图 2 中，每个请求的持续时间显示为深蓝色，并相对于页面装载的启始时间显示。所以，可以看出哪些请求使整个页面的装载变慢了。
尽管关注的重点是页面装载时间和用户体验，但是也不要忽视核心系统指标，比如磁盘、内存和网络。有许多实用程序可以捕获这些信息；其中最有帮助的可能是 sar、vmstat 和 iostat。关于这些工具的更多信息，请参见  一节。