统计表格展示了新版和旧版统计信息的主要区别，包括每一个信息改动的实际数字以及百分比。上图显示，新版的请求等待时间仅仅为旧版的8%。统计表格详细展示了每一个统计信息的改变，这些统计信息我们在”详细信息“页面能够经常看到；你可以对任何一列进行排序以便查找你感兴趣的信息。
一旦你在某一方面成功的进行了重构，查看详细信息页面（detail page)以检查新版本的实际效果，然后挑选其他方面进行优化。尝试对内存使用或者exclusive wall time 进行排序，以便挑选能够最大限度提高应用整体性能的函数进行优化。同时，不要忘记检查调用的次数，一个重复调用的函数经过优化之后能够成倍的提高程序的性能。
最优化方法
你很难在量化成果之前知道自己改善了多少，这就是为什么我们经常在对一个应用进行优化之前检测它--不然你怎么知道自己是否真的优化了它？我们也需要想想一组真实的数据应该怎样表示，不然，我们可能会朝着一个不可能到达的目标前进。一个很有用的方法是：尽力去寻找需要使用的最适合的数据结构以及最小存储空间。如果在你擅长的工作环境中，不能在半秒内运行一个“Hello world”程序，那么就别指望用同样的工具构建的网页能有多好的表现。
上面的叙述并不是对编程框架（framework）的不敬；编程框架之所以存在是因为其方便使用、支持快速开发、容易维护。相比亲自手工编写代码，编程框架在性能上的降低是我们综合各方面进行折中的结果。采用编程框架进行应用开发是能够尽快上线的一种很好的方法，当需要的时候，你可以使用Profiling工具分析并改进程序的性能。例如，Zend Framework 1的很多模块能够提供非好强大的特性，但是并能非常低下；采用Profiling工具就能确定性能低下的部分并将它们进行替换。其他所有的框架都有类似的问题，XHGui能够向您展示问题的所在并检查他们是否对你的程序产生了可量化的影响。
在你的程序之外，一些其他的策略对占领上风或许迟早有用:
当心非危险的慢速关联函数（not-dangerously-slow-but-related functions）在一个页面上露面。如果你的页面在格式化要点处理的 view helper 中的一系列函数中花去了它时间的 50%（我承诺这是个假想的例子），那么你可能想要去研究重构整个组件。
少做。尝试移除特性，如果性能比它们重要。
当心一个请求中生成但没有在特殊的视图中用到的内容，或未改变却被多次重新生成的内容。
好的缓存策略。这将是关于它的另一篇文章，但是考虑用 PHP 中的一个 OpCode 缓存（从 PHP 5.5 起内置），在你的 web 服务器前方添加一个反向代理，简单地为那些不怎么经常改变的内容发送适当的缓存头。
暴力去耦合。如果有一个可怕的资源紧张的特殊功能，把它从你的 web 服务器上去掉。或许它可以被异步处理，所以你的程序可以仅仅添加一个消息到队列，或移动到另一个单独的服务器并作为一个单独的服务模型来访问。无论哪种方式，分离将帮助减少你的 web 服务器的负载，同时启用了有效的扩展。
XHGui是你的朋友
XHGui安装简单、使用时如影随形、很棒的输出以至于可以拿到董事会议上进行展示。它能识别出我们应用中的错误，帮助我们确认应用真的起作用（或者没有！）。这可能会经历一些重复的过程，不过，不管你之前有没有用过XHProf、XHGui，我劝你花点时间在你的应用上试试，你会对你的发现大吃一惊。