Yon Faith

作者 EasyChen(at)Gmail.com
来源 http://qtutu.com/blog/?p=333

按照所谓的80-20定律，80%的性能瓶颈总是在20%的代码上，如果我们能够找出这20%的代码，就能够用最少的投入取得最大的收益。而Xdebug，正是这样一个工具。

1 Xdebug的安装

目前我还没有把Xdebug当作Zend扩展完美的装上去过，不过当成php扩展也不错，这里简单介绍下在win下安装Xdebug的方法（Linux自己编译一个.so也是一样的了）： 

1. 从http://pecl4win.php.net/ext.php/php_xdebug.dll 上下载你php版本对应的dll文件
2. 把这个dll文件放到php的扩展目录下
3. 确保dll所在的文件在php.ini中extension_dir下 
4. 在php.ini中添加如下配置
   

   extension=php_xdebug.dll [Xdebug] xdebug.profiler_enable=on xdebug.trace_output_dir="E:wamptmpxdebug" xdebug.profiler_output_dir="E:wamptmpxdebug"

5. 重启Apache

上边的E:wamptmpxdebug 就是用来存放Xdebug输出文件的地方。

2 安装WinCacheGrind。

Xdebug输出了一大堆显然不是给人类看的数据，那么我们怎么从中找到我们想要的呢？答案是，用WinCacheGrind。

从这里下载 http://sourceforge.net/projects/wincachegrind/ 安装我就不多说了。

3 调试开始

装好Xdebug后，通过浏览器访问要测试的页面，会在profile_output_dir下生成一个名为cachegrind.out.*的文件，用WinCacheGrind打开这个文件。

最重要的就是右边line_by_line的时间，前边一个是页面本身的时间，后边一个是页面累计载入时间。

双击可以打开详细的说明，我们来看看为什么这个页面要1000+ms才能加载上。

首先是load_module 这个是因为用了front_controller模式，所有的mod都是通过它加载的。继续往下看：

看来是Riki页面比较慢。

分析下去

看来慢的原因有三个。解析riki数据、取得riki数据和加载模板。

分析第一个，发现是由于有多个riki插件查询数据库导致的。

Digg插件耗掉了148ms。

取得最新用户的插件耗掉了130ms。

但是实际上最新用户之类的并不需要实时显示，我们可以在实时性要求不高的插件里边加上cache机制。

再来看riki数据的载入

创建数据连接居然耗掉了236ms，偶的破机器啊；主要耗时函数是mysql_connect，改为持久链接会快一些。

模板加载也用14ms，有点多，看看。

原来是header页面载入慢。

主要是几个管理查询函数消耗时间，但是对普通用户并不会进行，所以暂时不管它。

根据上边的分析，做了相应的修改，看看结果。

看起来还不错。不过这样刷新的数据参考价值并不是太大，还是用AB或者http_load进行压力测试才能反映出真实的情况。