Skip to content

Jesse's Software Engineering Blog

Feb 15


Analyzing PHP Code with Xdebug

Xdebug is a PHP extension that allows you to profile and debug your PHP code. It enables you to get detailed breakdowns of memory usage, function call costs, code efficiency, etc. on both your PHP scripts and HTTP page loads. Xdebug offers many unique features and it’s an invaluable tool for analyzing code during the development process.


You will need a couple prerequisite packages before installing Xdebug:

yum install php-devel php-pear

Use PECL to install:

pecl install xdebug

After installation find the module, it is usually located somewhere in /usr/lib, and create the .ini file for it:

sudo find /usr/lib/ -name
sudo vi /etc/php.d/xdebug.ini

; add the extension to the .ini file

Reload the server’s config file and verify the module was loaded:

sudo service httpd reload
php -m | grep xdebug

Later I discuss using the WebGrind tool for analyzing profile data. To install:

cd /var/www/html
curl -O


Xdebug has various features for different types of debugging and profiling. All of these features can be found in their documentation along with the functions and settings required to use them. Here are some of the common features I use:

Display Features – Allows for different color/styling and limitations on the amount of data that can be var dumped.

Stack Traces – Set different levels of error message to be displayed along with different formatting and output styles.

Function Traces – Function traces will show you the order in which functions are called in a script along with optional information such as time, parameters, return values, etc. Instead of using a combination of var_dump() and die() to track how data is manipulated throughout a script execution, you can simply turn on function tracing and you will get all the information you need. This is a very useful tool when debugging.

Code Coverage – This gives you data to determine which lines in your script are being hit. If you have complex conditionals, or other elaborate control structures, and you want to know which ones are getting hit you can use code coverage. You start it with xdebug_start_code_coverage() and retrieve the results with xdebug_get_code_coverage() which will return an array specifying which lines (by line #) of code were executed since code coverage was started.

Profiling – The profiler is the tool that I use the most. It allows you to analyze your PHP scripts and see every function call that is made and the overall cost of the calls. This allows you to analyze which areas of your code are performing the slowest and show specifically which calls are taking the most time. This is useful in not only analyzing page load times, but also in monitoring how your page will handle larger data loads. There are various UIs that can be used along with the profiler to help analyzize the data, with KCachegrind being a very popular and robust option. I like to use WebGrind which implements a subset of KCachegrind’s features but is easy to install and runs quickly. Profiling is expensive, it will consume a lot of resources and creates large file and should not be run in a production environment. This is a tool for analyzing your code during the development process. To enable the profiler you will need the following settings in your .ini file:

xdebug.profiler_enable – Toggles the profiler on and off

xdebug.profiler_output_dir – Where the logs are written to. Defaults to /tmp. Folder needs correct permissions for PHP to write to.

After you set the .ini vars and reload the webserver conf file, you can test the profiler is working by running a PHP script or loading a page through the browser. You should see a cache grind file in your specified output directory. To view the file you will need to have a UI installed, see above. For WebGrind, simply place the folder in your www root and pull the UI up via the browser. WebGrind will be able to find the cache grind file and display it. For more information on how to use the tool visit the WebGrind documentation. Note you can do this remotely, for example on a staging server, as long as the WebGrind index.php file is accessible via a browser. You’ll want to make sure you secure the directory though to keep the profiling only available to internal users.

Blog Powered By Wordpress