php-trunk macport

dsp — Mon, 24 May 2010 15:48:39 +0000

macports is a widely used ports system for Mac OS. It’s repository contains hundreds of application that can be compiled and installed. The repository contains php 5.3. So if you want to run PHP from subversion you still have to compile it yourself and install it yourself outside your managed ports environment. I created a rather simple Portfile to build it from PHP’s trunk.

To use the php-trunk portsfile. Just extract the tarball into a directory and…
$ tar xzvf php-trunk-port.tar.gz $ cd php-trunk-port $ echo "file://`pwd`" > /opt/local/etc/macports/sources.conf $ echo "file://`pwd`" >> /opt/local/etc/macports/sources.conf $ port install php-trunk

And the best thing about the port: It compiles PHP with dtrace support :).

Please note the Portfile is very simple and is not tested with the additional modules provided by macports. So use it at your own risk and enhance it.

DOWNLOAD

UPDATE: as philip noted, it should be >> instead of >.

PHP 5.3.99-dev and DTrace Part I

dsp — Tue, 27 Apr 2010 17:10:13 +0000

For those not following the PHP development. We backported the DTraces probes from the abandoned PHP 6.0 branch, back to the new trunk PHP 5.3.99-dev. It is called 5.3.99 because the PHP dev community has not decided yet on a version number (5.4 or 6.0).

To compile PHP with DTrace, on Solaris or Mac OS do:

  $ svn co http://svn.php.net/repository/php/php-src/trunk php
  $ cd php
  $ ./buildconf --force
  $ ./configure --enable-dtrace
  $ make

To check if your PHP has DTraces probes enabled, you can check the phpinfo() using

 $ php -i | grep DTrace

or use DTrace directly>

 $ sudo dtrace -ln 'php*:::' -c 'php -m'

88836    php4614               php               dtrace_compile_file compile-file-entry
88837    php4614               php               dtrace_compile_file compile-file-return
88838    php4614               php                        zend_error error
88839    php4614               php  ZEND_CATCH_SPEC_CONST_CV_HANDLER exception-caught
88840    php4614               php     zend_throw_exception_internal exception-thrown
88841    php4614               php           dtrace_execute_internal execute-entry
88842    php4614               php                    dtrace_execute execute-entry
88843    php4614               php           dtrace_execute_internal execute-return
88844    php4614               php                    dtrace_execute execute-return
88845    php4614               php                    dtrace_execute function-entry
88846    php4614               php                    dtrace_execute function-return
88847    php4614               php              php_request_shutdown request-shutdown
88848    php4614               php               php_request_startup request-startup

Have fun with DTrace in PHP.

A few examples will follow in the next days.

DTracing PHP

dsp — Sat, 20 Dec 2008 01:22:09 +0000

Dtrace is an extremely flexible and powerful tool to trace and debug applications. I recently dtraced PHP a little bit, so here is a tutorial how to start dtracing PHP.
Prequisites
You need a dtrace capable operating system like Solaris 10, OpenSolaris, Mac OS X 10.5 or FreeBSD 7. I use dtrace on OpenSolaris 2008.11. You also need at least dtrace privileges or need to be root to be able to trace a program. I used PHP 5.3.0alpha3 in my tests, but it actually doesn’t matter. As PHP doesn’t provide DTrace probes itself we have to trace the underlying C-functions, therefore we need to know the Zend Engine and PHP’s internals.

An Introduction into DTrace
Dtrace is really powerful and trying to do an introduction to all it’s features is just not possible. Therefore I will just focus on the basics, that are needed to get our stuff working. The basic idea behind Dtrace is that the kernel and userland programs fire probes on a specific location in the kernel or the userland program. As the probe is just fired if DTrace is running and trying to catch those markers, the probes itself don’t cost CPU power at all (in fact they are NOP’s). But if we trace them, we are able to see those probes and they are able to pass some data. To get way more complex information out of those probes, DTrace has an builtin scripting language that catches those probes and process them.

Dtrace program structure
Every probe in DTrace is describe by a 4 tuple. The first one is the so-called provider. The second, the probemodule, the third is the probefunc and the last one is the probename. The parts are separated by a semicolon, therefore every probe is defined by:

:::

In our example, the provider will usually the pid provider that gives us probes for a given PID (the PHP controller we want to trace). The probemodule will be php and the probefunc will be the function name of the underlying C-function. The name can actually be everything but it is best-practice to have a probe at the entry of a function, called entry and returnjust before the function returns. A DTrace program have an probe identifier that matches a probe. Every identifier has a body that can contain initialization of variables or accumulation of data using a table. Also, every identifier can have a condition that is evaluated before the body is run. So we have the following structure:

:::
/ /
{

}

As an example, we trace gc_collect_cylce function:

pid$target:php:gc_collect_cycle_function:entry
{
trace(probename);
}

Please notice that DTrace features a lot predefined variables, such as probename. Please refer to Sun’s Dtrace Guide to get a list of predefined variables.

PHP probes
~~As PHP doesn’t provide own probes we have to use the underlying C-functions.~~ PHP itself doesn’t provide own probes. There is ext/dtrace written by Wez Furlong which gives PHP some probes, but as we want to get a little bit deeper, we have to use the underlying C-functions. Userland programs are usually traced by the so-called pid-provider. It’s used to get all probes by a program with a given PID. Unlike userland programs, the kernel doesn’t have a pid, therefore kernel probes do not have a PID and can be identified easily be an unique name. As we sometimes do not know the PID of the php process that we want to trace, there is a variable called $target. If yo use it, $target will be automatically filled with the PID that was created when dtrace started the program. If I start a program with dtrace -s test.d -c ‘php test.php’ the programm php test.php will be executed and the created PID will be assigned to the variable $target. DTrace also have an option just to display the available probes: Try dtrace -ln ‘pid$target:php::entry’ -c ‘php test.php’ to get all function entries called by PHP. You might from time to time a get a message that not enough memory was available to trace. In those cases you just tried to capture too much probes. Therefore, I used the specific :::entry notation to just get function entries, which worked fine on my machine. So let’s take look at some interesting probes. If we just try to display all probes related to PHP with dtrace -ln ‘pid$target:php::entry’ -c ‘php test.php’.
The output might start with something like:

ID PROVIDER MODULE 69608 pid2696 php 69609 pid2696 php 69610 pid2696 php 69611 pid2696 php 69612 pid2696 php 69613 pid2696 php 69614 pid2696 php 69615 pid2696 php 69616 pid2696 php 69617 pid2696 php 69618 pid2696 php 69619 pid2696 php 69620 pid2696 php 69621 pid2696 php 69622 pid2696 php 69623 pid2696 php 69624 pid2696 php 69625 pid2696 php 69626 pid2696 php 69627 pid2696 php FUNCTION NAME
_start entry
__fsr entry
_free_ereg_cache entry
zm_startup_ereg entry
zm_shutdown_ereg entry
zm_info_ereg entry
zif_ereg entry
zif_eregi entry
php_ereg_replace entry
zif_ereg_replace entry
zif_eregi_replace entry
zif_split entry
zif_spliti entry
zif_sql_regcase entry
php_regcomp entry
p_ere entry
p_ere_exp entry
p_str entry
p_bre entry
p_simp_re entry

First example
So our first example will be that we want to trace the compilation time. The compile function is called compile_file in PHP. Therefore our probe identifier would be pid$target:php:compile_file. The PID provider will just get the probes for a specific probe, while the php probemodule will focus on all PHP related functions. We then select the compile_file function. Provided by the kernel, there are two probenames, calle entry and . Entry is called when the function is entered and return, when the function returns. So we need to trace pid$target:php:compile_time:entry and pid$target:php:compile_time:return. We know just have to get information how long the compilation takes. For that purpose DTrace defines a variable called timestamp that is accessible within the body of an DTrace identifier which holds the milliseconds from the beginning of a program. So know we catch our entry probe and set the time to a local value:

pid$target:php:compile_file:entry
{
self->compile_start = timestamp;
}

Note that the self-> notation is used to get a per-thread variable. Therefore every thread would have it’s own value. It’s not particularly necessary for our PHP based example, but it is best-practice to use thread-local variables whenever possible.

We just need our return probe that calculates the real offset:

pid$target:php:compile_file:return
{
printf(“Compile time: %dn”, timestamp – self->compile_start);
}

This will output our actual compile time. Just put both identifiers and their bodies into ‘compiletime.d’ and start dtrace with dtrace -q -s compiletime.d -c ‘php test.php’ and it will display you the compilation time of test.php. Please notice that both self->compile_start and timestamp are integers. Dtrace in fact doesn’t have the notion of a float primitive, so you would not be able to output a float using printf.

The output might be similar to:

$ dtrace -q -s compiletime.d -c ‘php test.php’
Compile Time: 99604

Advcanced Example
Now let’s get a little bit deeper into the engine. We now want to trace when the garbage collector hit’s in and want to see the amount of freed refs. The garbage collector uses the function gc_collect_cycles.

pid$target:php:gc_collect_cycles:return
{
printf(“%d refs freed”, arg1);
}

Please notice the special arg1 variable. This always holds the return value in “return” probenames. In “entry”, arg0…argN will hold the function parameters.

For more detailed examples, see my next blog entry, which will contain more sophisticated DTrace scripts.

experimentalworks » dtrace

php-trunk macport

PHP 5.3.99-dev and DTrace Part I

DTracing PHP