Trace - Debug ( Profiling ) PHP script by xdebug & kcachegrind

Step 1 : Install XDebug

xdebug is an open source debugger available for PHP. xdebug can be used to display more information in error traces. It can also be used to collect detailed code coverage & profiling information.

Installation

You need to install following packages to prepare environment for installation of pecl module xdebug.

sudo apt-get -y install php-pear php5-dev build-essential

Now we install xdebug using pecl.

sudo pecl install xdebug

Above command will download, compile & install xdebug on your system.

Configuration

Open usr/local/lib/php.ini and append following line.

zend_extension=/usr/lib/php5/20060613/xdebug.so

Be careful about that number part in the path as it could be different for you. Now restart apache by issuing following command.

sudo apache2ctl restart

Now try to view the output of your phpinfo() function. If you find xdebug word in that then it means you have successfully installed xdebug.

Stacktrace

xdebug.collect_params accepts values from 1 to 4. Where 1 refers to less verbosity & 4 refers to maximum verbosity while displaying stack traces. The easiest way of setting this option is using function ini_set in PHP.

ini_set("xdebug.collect_params", )

Get to know more stack trace options of xdebug.

var_dump

Once after installing xdebug when ever you call var_dump you are actually calling xdebug version of var_dump instead of built in one. By default xdebug version of var_dump gives you friendly info on the variables you are trying to inspect.

See more options on controlling display of var_dump information.

Debugging

xdebug uses DBGp protocol to communicate with external debuggers. Vim already has a plugin to do that. So you can debug php scripts from within vim.

Download php debugger plugin for vim.

Step 2: Enable Profiling

You need to add following line to /usr/local/lib/php.ini to enable profiling of php scripts.

xdebug.profiler_enable=1

Now restart the apache server by issuing following command.

sudo apache2ctl restart

When ever you access a php page through apache, xdebug will create a file something like cachegrind.out.15093. xdebug by default uses /tmp directory to dump files which contain profiling information. You can change this target directory by using xdebug option xdebug.profiler_output_dir and you can change result file name by using the option xdebug.profiler_output_name.

See more xdebug profiling options.

Some times you don't want to profile all requests. xdebug provides a selective mechanism to trigger profiling of specific requests. In order to enable this option you have to add following configuration option to php.ini.

xdebug.profiler_enable_trigger=On

Now you can trigger profiling of specific requests by adding XDEBUG_PROFILE to the query part of the GET request.

Analyzing Profiling results

We need to use kcachegrind to analyse profile file results. We can install kcachegrind by issuing following command.

sudo apt-get -y install kcachegrind

Now open your profle result file in kcachegrind and you can visuall inspect which part of your script is eating cpu resources. Callmap & Callgrap provide easy to understand visualizations to find bottlenecks in your script.

SQL Joins by venn diagram

If you have tried to understand how joins work and constantly get confused about what join to use, you just need to keep a simple picture in mind ( I like pictures). I will be explaining joins by referencing a Venn diagram. Have no fear - I won’t get into any of the set theory/math involved. This is just a basic overview to give you an idea the data a particular join will return to you. This is not a technical discussion - just concepts.

We will start with just an empty diagram:

The T1 circle represents all the records in table 1. The T2 circle represents all the records in table 2. Notice how there is a bit of overlap of the 2 circles in the middle. Simple right?

I will use red to signify the records that will be returned by a particular join.

INNER JOIN
An inner join only returns those records that have “matches” in both tables. So for every record returned in T1 - you will also get the record linked by the foreign key in T2. In programming logic - think in terms of AND.

OUTER JOIN
An outer join is the inverse of the inner join. It only returns those records not in T1 and T2. “Give me the records that DON’T have a match.” In programming logic - think in terms of NOT AND.

LEFT JOIN
A left join returns all the records in the “left” table (T1) whether they have a match in the right table or not.

If, however, they do have a match in the right table - give me the “matching” data from the right table as well. If not - fill in the holes with null.

It should be noted that the same thing is possible with a right join - most people just use a left one.

LEFT OUTER JOIN
A left outer join combines the ideas behind a left join and an outer join. Basically - if you use a left outer join you will get the records in the left table that DO NOT have a match in the right table.

Again it is noted that the same thing is possible with a right outer join - most people just use a left one.

Theta JOIN
A theta join is the Cartesian product of the 2 tables and not normally what people are looking for - but what they sometimes get by mistake. How many of us have written a join similar to this only to get way more then we were ever expecting.

SELECT t1.*, t2.*
FROM table1 t1, table2 t2
WHERE t1.id = 5;


So there you have the basic concepts of joins. Next time you need to use a join and have no clue what to do to get the data you need from the database, draw a picture. It may help you figure out what join to use. Least it helps me.