安装XHGui

XHGui本身主要由web页面组成，它为XHProf扩展收集的数据提供更加友好的界面。你可以从代码库GitHub repo克隆；也可以直接下载zip文件，然后进行解压缩。获取程序之后，确定缓存目录有足够的权限以便web服务器有权限写入文件。最后，运行安装脚本：

这就是程序安装所需的一切，并且会自动安装一些依赖程序；如果发生异常，安装程序也会给你提示。

我更喜欢将XHGui安装在虚拟主机当中；这需要.htaccess文件允许，也需要启动RUL重写。启动URL重写表明需要启动mod_rewrite模块，通过下面的命令：

（不要忘记重启Apache）。如果一切顺利，你可以正常访问XHGui的URL并且可以看到如下内容：

在虚拟主机中启动XHGui

此时，我们希望启动XHGui以便检验我们网站的性能。注意，性能测试最好在进行任何优化之前执行一次，以便检测优化的效果。最简单的方法是在虚拟主机中增加auto_prepend_file声明，如下图所示：

一切就绪之后，你可以开始剖析网站的请求。XHGui只会剖析网站请求的1%，所以为了使XHGui获取有意义的数据，你需要让XHGui运行一段时间或者使用类似Apache Bench的测试工具批量提交一批请求。为什么在100个请求当中XHGui只会剖析一个？因为XHGui的设计初衷就是足够的轻巧以便在生产环境中使用，它不想对每一个请求产生额外的开销，1%的采样率已经能够为网站的总体流量提供较为清晰的概览。

满足数据

我使用测试虚拟机运行本文所有的示例，采用作为测试代码。为了产生一些流量，我将API测试案例运行了几遍。你也可以在一定负载的情况下收集数据，所以你可以在压力测试时使用XHGui，你甚至可以在上线站点中使用XHGui收集数据（听起来很疯狂，但是Facebook正式为了此应用才开发了该工具）。在向应用发送了一定的请求之后，重新访问XHGui，现在它就已经保存了一些数据：

@H_404_0@

@H_404_0@该图向我们展示了XHGui为我们分析的每一个请求，最新的请求排在第一位，并且为每一个请求展示了一些额外信息。这些信息包括：

• URL：请求所访问的URL
• Time：请求发起时间
• wtor： "Wall Time" –请求所经历的所有时间. 这是 "wall clock" time的简称,表示用户等待请求完成所有的时间
• cpu：花费在该请求上的cpu时间
• mu：该请求所消耗的内存
• pmu：请求处理过程中所消耗的最大内存

@H_404_0@为了获取每一遍请求（"run")更为详细的信息，你可以点击每一个请求你感兴趣的列。你可以点击URL以便获取该URL所有请求的详细信息。无论哪种方法，你都可以获取该请求更为详细的信息：

@H_404_0@

@H_404_0@

@H_404_0@这是一个非常长并且非常详细的页面，所以我引用了两个截图（如果展示所有的信息将需要5个截图）。上面一幅图的左边部分展示了该请求相关的一些信息，以便帮助你跟踪这些统计信息与哪些方面有关；右边的主要部分展示了最消耗时间的各部分以及在请求过程中每个函数调用所消耗的内存。在图的下方有一个主键以表明每一栏。

@H_404_0@第二幅图展示了该请求每一个组成部分更为详细的信息。我们可以看到每一部分调用的次数以及时间消耗，还包括cpu和内存信息。无论是inclusive还是exclusive信息都做了详细的展示：exclusive表示仅仅是该方法调用所产生的消耗；inclusive不仅包括本函数所产生的消耗，还包括本函数调用的其他函数所产生的消耗。

@H_404_0@ XHGui另一个特性是“调用图”（Callgraph)，“调用图”以生动的虚拟方式展示了时间是如何消耗的：

@H_404_0@

@H_404_0@这很好的展示了函数调用的层次。最好的一点是，该图是可交互的，你可以拖拽以更好的查看连接；你还可以用鼠标滑过“圆环”（blob)以查看更多的信息。当你与它交互时，他会很好玩的弹回和移动，这不是一个非常重要的特性但却让我感觉非常好玩。

@H_404_0@

理解数据

@H_404_0@拥有大量的统计数据非常重要，但是你很难知道从哪里下手。对于一个性能不如预期的页面采用如下步骤：首先，对每一个函数的exclusive cpu时间进行排序，查看最消耗时间的函数列表。分析这些耗时的函数调用并进行重构和优化。

@H_404_0@一旦做出了修改，让剖析工具再次检验新版本的程序，测试性能的改进。XHGui内置了完美的工具以比较两次运行；点击详细信息页面右上角的“Compare this run"按钮即可。该按钮会向你展示该URL每一次测试的结果，从中选择一个你要比较的对象。对你想比较的对象，点击”compare“按钮，XHGui将会转向比较视图，如下图所示：

@H_404_0@

@H_404_0@统计表格展示了新版和旧版统计信息的主要区别，包括每一个信息改动的实际数字以及百分比。上图显示，新版的请求等待时间仅仅为旧版的8%。统计表格详细展示了每一个统计信息的改变，这些统计信息我们在”详细信息“页面能够经常看到；你可以对任何一列进行排序以便查找你感兴趣的信息。

@H_404_0@一旦你在某一方面成功的进行了重构，查看详细信息页面（detail page)以检查新版本的实际效果，然后挑选其他方面进行优化。尝试对内存使用或者exclusive wall time 进行排序，以便挑选能够最大限度提高应用整体性能的函数进行优化。同时，不要忘记检查调用的次数，一个重复调用的函数经过优化之后能够成倍的提高程序的性能。

@H_404_0@

最优化方法

@H_404_0@你很难在量化成果之前知道自己改善了多少，这就是为什么我们经常在对一个应用进行优化之前检测它--不然你怎么知道自己是否真的优化了它？我们也需要想想一组真实的数据应该怎样表示，不然，我们可能会朝着一个不可能到达的目标前进。一个很有用的方法是：尽力去寻找需要使用的最适合的数据结构以及最小存储空间。如果在你擅长的工作环境中，不能在半秒内运行一个“Hello world”程序，那么就别指望用同样的工具构建的网页能有多好的表现。

@H_404_0@上面的叙述并不是对编程框架（framework）的不敬；编程框架之所以存在是因为其方便使用、支持快速开发、容易维护。相比亲自手工编写代码，编程框架在性能上的降低是我们综合各方面进行折中的结果。采用编程框架进行应用开发是能够尽快上线的一种很好的方法，当需要的时候，你可以使用Profiling工具分析并改进程序的性能。例如，Zend Framework 1的很多模块能够提供非好强大的特性，但是并能非常低下；采用Profiling工具就能确定性能低下的部分并将它们进行替换。其他所有的框架都有类似的问题，XHGui能够向您展示问题的所在并检查他们是否对你的程序产生了可量化的影响。

@H_404_0@
在你的程序之外，一些其他的策略对占领上风或许迟早有用:

• 当心非危险的慢速关联函数（not-dangerously-slow-but-related functions）在一个页面上露面。如果你的页面在格式化要点处理的 view helper 中的一系列函数中花去了它时间的 50%（我承诺这是个假想的例子），那么你可能想要去研究重构整个组件。
• 少做。尝试移除特性，如果性能比它们重要。
• 当心一个请求中生成但没有在特殊的视图中用到的内容，或未改变却被多次重新生成的内容。
• 好的缓存策略。这将是关于它的另一篇文章，但是考虑用 PHP 中的一个 OpCode 缓存（从 PHP 5.5 起内置），在你的 web 服务器前方添加一个反向代理，简单地为那些不怎么经常改变的内容发送适当的缓存头。
• 暴力去耦合。如果有一个可怕的资源紧张的特殊功能，把它从你的 web 服务器上去掉。或许它可以被异步处理，所以你的程序可以仅仅添加一个消息到队列，或移动到另一个单独的服务器并作为一个单独的服务模型来访问。无论哪种方式，分离将帮助减少你的 web 服务器的负载，同时启用了有效的扩展。

@H_404_0@

XHGui是你的朋友

@H_404_0@XHGui安装简单、使用时如影随形、很棒的输出以至于可以拿到董事会议上进行展示。它能识别出我们应用中的错误，帮助我们确认应用真的起作用（或者没有！）。这可能会经历一些重复的过程，不过，不管你之前有没有用过XHProf、XHGui，我劝你花点时间在你的应用上试试，你会对你的发现大吃一惊。