现在的位置: 首页 > 综合 > 正文

WAMP配置扩展Xdebug

2013年05月11日 ⁄ 综合 ⁄ 共 3432字 ⁄ 字号 评论关闭

Xdebug现在的最新版本是xdebug 2.0.2:“Windows modules for PHP 5.1.2-5.1.7Windows modules for PHP 5.2.1-5.2.7

 

现在对应PHP版本的xdebug扩展

 

php文件夹中的php_ini文件写入下面

extension=php_xdebug.dll

[Xdebug]
xdebug.profiler_enable=on
xdebug.trace_output_dir="d:/phpProjects/xdebug"
xdebug.profiler_output_dir="d:/phpProjects/xdebug"
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp

apache文件夹中的PHP_ini文件写入

extension=php_xdebug.dll

[Xdebug]
xdebug.profiler_enable=on
xdebug.trace_output_dir="d:/phpProjects/xdebug"
xdebug.profiler_output_dir="d:/phpProjects/xdebug"
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp

 

xdebug.trace_output_dir,xdebug.profiler_output_dir这两个路径可根据需要更改

 

//-----------------以下转自http://noizy.blog.sohu.com/82893530.html

现在我们就可以开始使用Xdebug强大的功能了!

 

Go on..现在我们来从最简单的程序调试开始一步步介绍Xdebug。

调试:

我们先写一个可以导致执行出错的程序,例如尝试包含一个不存在的文件。

test.php

<?php
require_once('abc.php');
?>

然后通过浏览器访问,我们惊奇地发现,出错信息变成了彩色的了:

不过除了样式改变,和我们平时打印的出错信息内容没什么不同,意义不大。好,我们继续改写程序:

 

test2.php

<?php
testXdebug();
function testXdebug() {
      require_once('abc.php');
}
?>

输出信息:

发现了什么?Xdebug跟踪代码的执行,找到了出错的函数testXdebug()。

 

我们把代码再写得复杂一些: 

 

test3.php

<?php
testXdebug();
function testXdebug() {
       requireFile();     
}
function requireFile() {
       require_once('abc.php');
}
?>

输出信息:

呵呵,也就是说Xdebug具有类似于JavaException的“跟踪回溯”的功能,可以根据程序的执行一步步跟踪到出错的具体位置,

哪怕程序中的调用很复杂,我们也可以通过这个功能来理清代码关系,迅速定位,快速排错。

其实PHP函数debug_backtrace()也有类似的功能,但是要注意debug_backtrace()函数只在PHP4.3.0之后版本及

PHP5中才生效。这个函数是PHP开发团队在PHP5中新增的函数,然后又反向移植到PHP4.3中。

如何利用Xdebug使调试信息更加美观?

Xdebug 扩展加载后,Xdebug会对原有的某些PHP函数进行覆写,以便好更好地进行Debug。比如var_dump()函数,

我们知道通常我们需要在函数前 后加上“<pre>…</pre>”才能够让输出的变量信息比较美观、可读性好。

但是加载了Xdebug后,我们不再需要这样做 了,Xdebug不但自动给我们加上了<pre>标签,还给变量加上颜色。

例:

<?php
$arrTest=array(
       "test"=>"abc",
       "test2"=>"abc2"
);
var_dump($arrTest);
?>
输出:

看到了吗? 数组元素的值自动显示颜色。

如何利用Xdebug测试脚本执行时间

测试某段脚本的执行时间,通常我们都需要用到microtime()函数来确定当前时间。例如PHP手册上的例子:

<?php
/**
* Simple function to replicate PHP 5 behaviour
*/
function microtime_float(){
    list(
$usec$sec) = explode(" "microtime());
    return ((float)$usec + (float)$sec);
}

$time_start microtime_float();
// Sleep for a while
usleep(100);
$time_end microtime_float();
$time $time_end $time_start;
echo 
"Did nothing in $time seconds/n";
?>

但是microtime()返回的值是微秒数及绝对时间戳(例如“0.03520000 1153122275),没有可读性。

所以如上程序,我们需要另外写一个函数microtime_float(),来将两者相加。

Xdebug自带了一个函数xdebug_time_index()来显示时间。

如何测定脚本占用的内存?

有时候我们想知道程序执行到某个特定阶段时到底占用了多大内存,为此PHP提供了函数memory_get_usage()。

这个函数只有当PHP编译时使用了–enable-memory-limit参数时才有效。 

Xdebug同样提供了一个函数xdebug_memory_usage()来实现这样的功能,另外xdebug还提供了一个xdebug_peak_memory_usage()函数来查看内存占用的峰值。

如何检测代码中的不足?

有时候代码没有明显的编写错误,没有显示任何错误信息(如errorwarningnotice等), 但是这不表明代码就是正确无误的。

有时候可能某段代码执行时间过长,占用内存过多以致于影响整个系统的效率,我们没有办法直接看出来是哪部份代码出了问 题。

这时候我们希望把代码的每个阶段的运行情况都监控起来,写到日志文件中去,运行一段时间后再进行分析,找到问题所在。

回忆一下,之前我们编辑php.ini文件

xdebug.profiler_output_dir="D:/temp/php/xdebug"
xdebug.trace_output_dir="D:/temp/php/xdebug"

这几行,目的就在于把执行情况的分析文件写入到“D:/temp/php/xdebug”目录中去(你可以替换成任何你想设定的目录)。

如果你执行某段程序后,再打开相应的目录,可以发现生成了一堆文件,例如cachegrind.out.2072这种格式命名的文件。

这些就是Xdebug生成的分析文件。用编辑器打开你可以看到很多程序运行的相关细节信息,不过很显然这样看太累了,我们需要用图形化的软件来查看。

Windows平台下,可以用WinCacheGrind(http://sourceforge.net/projects/wincachegrind)这个软件来打开这些文件。可以直观漂亮地显示其中内容:

这样我们就可以非常方便地查看整个脚本的程序结构。

另外,我们还可以看到每个函数被调用的次数及执行所花费的时间!这对于测试程序性能非常有用。

好了,根据上面图示例子(PHPWind Forums v6.3RC版index.php),可看出Xdebug+WinCacheGrind的强大、精细,整个程序的结构,每个函数被调用的次数,执行时间都一目了然。

小结:Xdebug提供了各种自带的函数,并对已有的某些PHP函数进行覆写,可以方便地用于调试排错;Xdebug还可以跟踪程序的运行,通过对日志文件的分析,我们可以迅速找到程序运行的瓶颈所在,提高程序效率,从而提高整个系统的性能。

抱歉!评论已关闭.