为 PHP 应用提速、提速、再提速!,第 3 部分 用 Memcache 守护程序把数据缓存到内存中.doc

简介：如果 PHP 应用程序运行缓慢，可以使用分析器找出应用程序究竟在哪些方面浪费了时间。可以将语句、循环、函数、类或者是运行缓慢的库作为分析目标。如果不是时间而是内存使用出现了问题，那么一个优秀的分析器还可以显示组件的内存占用情况。查看本系列更多内容本文的标签： php_(hypertext_preprocessor), 优化, 应用开发, 性能标记本文！发布日期：2007 年 3 月 21 日 级别：中级 访问情况2810 次浏览 建议：0(添加评论) 平均分 （共 4 个评分 ）“为 PHP 应用提速、提速、再提速！” 系列文章的 第 1 部分 演示了如何使用 XCache（PHP 操作码缓存） 加速整个站点。XCache（仅是少数几种缓存包中的一种）保留了编译过程的输出，去掉了其他冗余的工作。只要页面没有发生变化，缓存后的页面就能够胜任 代理的作用。当页面发生变化时，缓存后的页面就会变为无效并被替换掉。操作码缓存 以及一个操作码优化器，通常由相同的包提供 是一种加快站点响应的低成本技术。很多缓存包是免费的，并且是开源的，无需改变任何代码即可从中受益。当然，在某些应用程序中，相比较实际的执行时间，将 PHP 源代码文件翻译为其相应的操作码所需的时间微不足道。连接到远程数据库服务器，使用低效的 SQL 语句进行查询，以及其他大量解析和操作数据的工作都非常的繁琐，也因此增加了开销，甚至产生浪费。良好的网络设计和灵巧的数据库结构可以使时间冗长和查询 缓慢的情况有所改善，如果需要的话还可以向友好的专家请求帮助。但是，如果代码运行缓慢，您可能更希望自己处理。但是从何开始呢？正如人们普遍认为的，在代码完成前调试代码的做法很不明智 因为代码的首次实现可能会非常的迅速。当代码正确且能实现相应的功能时，不管其表面上看起来运行缓慢还是实际如此，首先要做的就是对其性能进行测试或基准测试。不执行这样的诊断而尝试去优化代码无疑是在黑暗中摸索。一个简单的性能指标是挂钟时间（wall clock time），或测量页面请求与完成呈现之间的实际延迟。对于某些情 况 比如在您自己的工作站本地运行的 Web 服务器、数据库和浏览器 挂钟时间能够提供信息。然而，挂钟时间对于其他大多数情况而言并无实际意义，比如网络延迟时间、活动的 Web 服务器或者活动的数据库。一种更精确的测量 甚至可以测量运行单个源代码语句的时间 可以采用代码分析器。分析器通常被实现为 PHP 运行时引擎的扩展，记录语句开始和结束的 delta、记录程序开始和结束之间的 delta 并捕获对来到的请求形成响应的总时间。有了这种垂直度，就可以将语句、循环、函数、类或者是运行缓慢的库作为分析目标。如果不是时间而是内存使用出现了问 题，那么一个优秀的分析器还可以显示组件的内存占用情况。 PHP 的一个较流行的分析器是 Xdebug，它还为交互地调试 PHP 应用程序提供了服务器挂钩（hook）。（参见“调试的更好方法”以了解更多信息。该系列的另一部分将探讨高级交互式调试。） Xdebug 很容易从源代码构建，将其作为 Zend 扩展进行安装也非常简单。（现在已有针对某些平台的二进制文件。）当就绪后，对基于 PHP 页面的每个请求都将生成可在 KCacheGrind 中查看的数据集。构建并安装 Xdebug如果具备了 PHP 实用工具 phpize 和 php-config，而且具有对 系统的 php.ini 配置文件的访问权，那么安装和设置 Xdebug 只需几分钟的时间。下面给出的指导说明针对 Linux，不过在 Mac OS X 上的安装步骤实际上与此类似。（您可以从 Xdebug Web 站点找到针对 Microsoft Windows 的 Xdebug 预编译版本。）Xdebug 的最新版本为 V2.0.0RC3（最终版本 V2.0.0 在您阅读此文时也许已经可用）。下载并解包 tarball，然后切换到源代码的子目录。确保 phpize 和 php-config 位于 shell 的 PATH，准备使用 phpize 进行构建。 清单 1. 设置 Xdebug$ wget /files/xdebug-2.0.0RC3.tgz$ tar xzf xdebug-2.0.0RC3.tgz$ cd xdebug-2.0.0RC3/xdebug-2.0.0RC3$ phpizeConfiguring for:PHP Api Version: 20020918Zend Module Api No: 20020429Zend Extension Api No: 20050606phpize 的产品是一个脚本 名为配置 它对余下的构建过程进行配置。要构建 Xdebug，在 make 后紧接着输入 ./configure 即可。清单 2. 构建 Xdebug$ ./configurechecking build system type. i686-apple-darwin8.8.1checking host system type. i686-apple-darwin8.8.1checking for egrep. grep -E.$ make.Build complete.(It is safe to ignore warnings about tempnam and tmpnam).make 命令生成 Xdebug 扩展，xdebug.so。剩下的工作就是使用 sudo make install 进行安装。$ sudo make installInstalling shared extensions: /usr/lib/php/extensions/no-debug-non-zts-20020429/注： 如果在终端窗口中运行最后一个命令，请选择并复制最后一步中发出的目录。在下一个步骤中将会用到它。最后，要使配置数据可视化，必须使用 KCacheGrind 和 GraphViz。包含 K Desktop Environment (KDE)的 Linux 发行版很可能已经含有了 KCacheGrind 和 GraphViz。如果没有包含，适合您所使用的 Linux 的那些版本也不难找到。Debian 用户可以使用 Advanced Packaging Tool (APT) 快速安装 KCacheGrind 和 GraphViz 以及所有包的依赖关系。清单 3. 安装 KCacheGrind$ apt-cache search kcachegrindvalgrind-callgrind - call-graph skin for valgrindkcachegrind - visualisation tool for valgrind profiling outputkcachegrind-converters - format converters for KCachegrind profiling visualisation tool$ apt-cache search graphvizgraphviz - rich set of graph drawing toolsgraphviz-dev - graphviz Libs and Headers against which to build applicationsgraphviz-doc - additional documentation for graphvizlibdeps-renderer-dot-perl - DEPS renderer plugin using GraphViz/dot.$ sudo apt-get install kcachegrind graphviz .如果没有将 KDE 安装到系统中，KCacheGrind、GraphViz 以及所有必要的内容将占用大约 90 MB 的磁盘空间。回页首配置 Xdebug安装了 Xdebug 扩展后，就可以准备启用和配置该扩展了。在文本编辑器中打开 php.ini，并添加以下代码行。 清单 4. 启用和配置该扩展zend_extension = /usr/lib/php/extensions/no-debug-non-zts-20020429/filer_output_dir = /tmp/xdebug/filer_enable = Ofiler_enable_trigger = 1第一行 zend_extension 加载 Xdebug 扩展。第二行命名放置分析器输出的目录。如果需要的话，创建命名的目标并更改其模式以允许用户对 Web 服务器进行写访问。第三行禁用了分析器。然而，第四行将在设置 HTTP GET 或 POST 参数 XDEBUG_PROFILE 时启用分析器。（如果您希望一直使用分析器，在第三行代码中将 Off 更改为 On。）添加这几行代码并验证了输出目录是可写的，然后重新启动 Web 服务器。对于其他 PHP 扩展，要验证 Xdebug 是否安装并可用，可以创建一个简单的骨架 PHP 程序来调用 phpinfo() 并查看结果。应该能够看到类似于图 1 所示的内容。（为简便起见，省略了完整输出的部分内容。）图 1. Phpinfo 指明 Xdebug 是否已安装您还可以向下滚动到 Zend 徽标。如果正确安装并配置了 Xdebug，它将显示在徽标的旁边。 回页首使用分析器要分析代码，只需将浏览器指向 PHP 应用程序即可。如果您将分析器设置为对每个触发逐个解决的方式，将 XDEBUG_PROFILE=1 追加到 URL 中，或者，像下面一样，将参数嵌入到表单中。作为一个示例，我们来分析一下这个简单的 ACME Fibonacci Maker，fibonacci.php，如清单 5 所示。为方便起见，将 XDEBUG_PROFILE 参数设置在表单的隐藏变量内。（当代码投入生产时，很可能将禁用 Xdebug，呈现这个变量将不会造成什么损失。）清单 5. Fibonacci.php?php function fib($nth = 1) if ( $nth ACME Fibonacci Maker Try the ACME Fibonacci Maker! Enter a number: st, 2 = nd, 3 = rd ); if ( $_REQUESTn 20 ) $suffix = $suffix$n; else $suffix = th; echo The . $_REQUESTn . $suffix . Fibonacci number is ; echo fib( $_REQUESTn ) . ; ? 将浏览器指向 http:/localhost/fibonacci.php（或者合适的 URL）并输入数字 比如，16。其结果 Fibonacci 系列的第 16 个元素 如图 2 所示。图 2. 示例 Fibonacci 应用程序如果将分析器输出目录中的内容（名为 php.ini）列出来的话，应该能看到类似 cachegrind.out.951917687 这样名称的文件。cachegrind.out. 前缀是固定的。默认情况下，数值后缀是目录路径到 fibonacci.php 文件的 CRC32 散列。因此，如果每一个应用程序都位于自己的目录，那么每个程序的输出将根据文件名而被分隔。（如果您更喜欢将输出与时间相关联，将下面这行代码：filer_output_name = timestamp添加到 php.ini。）从终端窗口启动 KCacheGrind 并打开 cachegrind.out.951917687。将立即打开一个类似于图 3 的新窗口。图 3. KCacheGrind 应用程序单击 Callees 选项卡，双击源代码中突出显示的行，并从 Grouping 列表选择 Source File 。所看到的视图应变为类似图 4 所示的内容。图 4. 查看结果正如您预期的一样，实际上全部的处理时间（70,989 毫秒的 99.87%）都花费在 3193 次对 fib() 函数的调用上了。要加快该应用程序（随着进一步执行 Fibonacci 序列，程序会随之变慢），应该避免重新计算 Fibonacci 数字这样代价高昂的重复工作。事实上，ACME Fibonacci Maker 能够很好地进行计算重用。 下面展示了 fib() 函数的优化版本。新的版本用内存换来了时间上的节省，因为它保留了中间的计算以便以后使用。图 5 展示了分析结果：与上次的 3192 次函数调用相比，这里仅需要 30 次调用（并且只有一半的调用需要计算结果），而时间则减少为只有 20 毫秒。清单 6. 更新了的 fib() 函数function fib($nth = 1) static $fibs = array(); if ( ! empty ($fibs$nth ) ) return( $fibs$nth ); if ( $nth 图 5. 加快了的 Fibonacci 函数虽然单次运行应用程序能够指出一些问题（可以试试上面原始的应用程序中的 Fibonacci 序列的第 50 个元素 ），通常，还是需要通过几次调用收集统计信息以及查看模式。如果保留默认的 “crc32” 命名模式，每次运行 fibonacci.php 时，将重写数据文件。然而，可以通过在 php.ini 中设置 filer_append = 1 改变这种行为并将后续运行追加到相同的文件。更改之后重新启动 Web 服务器。图 6 显示了三次运行 Fibonacci Maker 之后数据合计的示例。总时间稍大于两秒；其中 99.97% 的时间花费在了 fib() 上。图 6 显示了 Call Graph 选项卡，它由 GraphViz 的 dot 工具生成。关于 KCacheGrind 的具体用法不在本文讨论的范围之内，但是可以从网上获得其完整的文档。KCacheGrind 可以以很多种方法对数据进行交叉分析，根据您希望解决的问题选择合适的方法。图 6. 合计分析数据调试的更好方法除了分析 PHP 应用程序，还可以在发生错误并进行交互式调试时，配置 Xdebug 扩展（如其名字暗示的一样）来提供详细的栈跟踪和错误消息。栈跟踪和错误消息可以指出错误的原因，而交互式调试允许每次逐步调试代码中的一条指令，查看程 序变量的类型和值，并检查所有的 PHP 超全局变量，包括进来的请求参数。本系列的下一篇文章将具体介绍交互式调试。同时，您可以启用几个 Xdebug 特性来说明应用程序在发生错误时的状态： 无论何时只要应用程序出现错误，设置 xdebug.default_enable=On 显示栈跟踪。如果您已经花费时间安装了 Xdebug，那么只要进行代码开发就启用这个特性。 还可以设置 xdebug.show_local_vars=1 来进一步显示最顶部范围内的所有变量。 xdebug.var_display_max_children、xdebug.var_display_max_data 和 xdebug.var_display_max_depth 是相关的三个设置，分别用来控制因 xdebug.show_local_vars 的使用而显示的变量的属性数、字符串长度和嵌套深度。可以在 Xdebug Web 站点找到更多信息。回页首分析类 如果没有具体的代码，那么很难演示具有意义的分析，下面这个示例是十分典型的代码，展示了从中所能获得的信息。清单 7 显示了一个装配玩具火箭的应用程序（人为设计）。这种玩具火箭由几个部分组成，生产每一个部分都需要一定的时间。在 PHP 中，使用类代表每个组成部分，使用实例方法表示每个部分的构造时间。您可以将这个玩具看作是一个应用程序，并把每个部分看作是该应用程序的功能。清单 7. 模拟玩具装配的一组 PHP 类build( MINUTE ); function build( $delay = 0 ) if ( $delay 0 ) class Capsule extends Part function Capsule() parent:Part(); $this-build( CAPSULE * MINUTE ); class Booster extends Part function Booster() parent:Part(); $this-build( BOOSTER * MINUTE ); class Stage extends Part function Stage() parent:Part(); $this-build( STAGE * MINUTE ); class SpaceShip var $booster; var $capsule; var $stages; function SpaceShip( $numberStages = 3 ) $this-booster = new Booster(); $this-capsule = new Capsule(); $this-stages = array(); while ( $numberStages- = 0 ) $stages$numberStages = new Stage(); $toys = array(); $count = PRODUCTION; while ( $count- = 0 ) $toys = new SpaceShip( 2 ); ?Toy Factory Output Toy Production Built 运行这些代码将生成一个新的数据文件。同样，将数据加载到 KCacheGrind。如果切换到 Source 和 Call Graph 选项卡，将看到类似图 7 所示的视图。图 7. 太空船应用程序的配置文件Flat Profile 窗格（左面）显示了应用程序调用的所有函数（方法）。最左面的列展示了近似的累计总数，第二列展示了每种方法的单独测试，第三列列出了调用该方法的次数。 在调用图表中使用有颜色的方块反映图表内容，这非常方便，能够很容易地将事件序列与其花费的时间关联起来。很明显，构建阶段所使用的时间代价最昂贵。构建每一部分所需的系统开销（使用 Part 的构造器表示）次之。再看一下 PHP 自身的 define() 函数，它只花费了很少的开销。最后，还可以查看内存的使用情况。从靠近顶部的下拉菜单中选择 Memory 和 Class，然后切换到顶部以及底部的 Types 和 Caller Map 选项卡。您看到的屏幕应该类似图 8。图 8. 太空船应用程序的内存使用情况回页首找回周期和其他众多 PHP 扩展一样，Xdebug 容易构建、安装快捷且易于配置 所有这些工作 10 分钟内即可完成。如果您已经优化了 Apache 安装并且对应用程序进行了缓存，但是性能仍然很差，那么可以考虑一下代码的运行。算