Kurt Payne has a new post to his blog showing how to use register_tick_function with a callback to help benchmark and profile your application to find its pain spots.

A profiler gives you the ability to trace the performance of your code through every function call and create an overview of your system's performance over a certain time period and helps you make intelligent decisions about where to look for problems. [...] But what if you're in an environment where you can't install [the xdebug or xhprof] extension? Luckily, php has a built-in function called register_tick_function that gives you a way to hook in to every user function that's called. With this, you can write a profiler yourself.

A bit of sample code illustrates his method - it defines a "do_profile" function and assigns it with the register_tick_function call. This function generates a debug backtrace and echos out the function path it took to get to that spot (output is included). He provides code for a bit more useful profiling and points out that it could easily be graphed to help visualize the problems. Also included are a few caveats to watch out for when using this method of profiling.

In a new post to his blog Joshua Thijssen gives a guide to how he usually sets up his development environments when working in PHP. It includes working with virtual machines, configuring DNS and setting up his tools to work with it all.

Doing development on multiple projects can be a burden from time to time. One project would be running on PHP 5.3, while another still needs 5.1. Sometimes you need a MySQL server, while on other occasions, you need a NoSQL solution like couchDB or MongoDB together with all kind of gearman functionality. This article shows you how I've setup such a development platform that allows you to quickly create new projects, and still maintain flexibility when you need it.

He uses VirtualBox with either a Debian or CentOS installation as a base platform. He uses Vagrant to set up and configure the machines to make setup almost automatic. He still has to go in and configure a few things like the VirtualHost and DNS settings for the site/application he's working on. Next up is setting up the tools he uses, specifically XDebug and setting up his editor of choice (PHPStorm) for remote debugging.

In response to a previous post benchmarking exceptions, Volker Dusch has posted some of his own thoughts and benchmarking results on the same topic.

Some days ago there was a blog post regarding php exception performance in 5.4 and the numbers got reported all over the place. The actually numbers are secondary. The main point is: Don't trust "random" stuff on the Internet when thinking about improving your application performance. You always need to measure things for your self and take care doing so! I've initially trusted the benchmark myself and disgraced the whole post saying: "Well yes, exceptions are slower than if statements but nice that they got faster".

He includes some results with a bit more standardized testing - one run with both 5.3 and 5.4 using XDebug and another with it turned off for both. His results make sense, if you think about them:

So what we learn from that? Running stuff with debugging tools is slower than not doing that. That's why we don't use xDebug in production.

In a recent post from Learncomputer.com, there's a comparison of two PHP profilers - the PHP Quick Profiler and the one included in Xdebug.

Whether you are an experienced developer or just getting started it is important to know how to measure the performance of your scripts and applications so that you can learn to make improvements and optimizations to your code. [...] This article compares two of the most popular [profiling] solutions under free license that you can begin using today to profile your PHP applications.

They describe each of the tools - the Quick PHP Profiler acting more like a plugin (running on each page load) and Xdebug working more behind the scenes and providing cachegrind files. These files can be viewed in cachegrind tools to drill in to the badly performing aspects of your applications and find the issues.

If you need a free tool it can be difficult to find a PHP profiling tool that has all of the features you may want and the interface that you like all rolled into one. Identifying what kind of data you are looking for and what information you need from a profiling tool will allow you to choose the best solution for your needs.

Derick Rethans has a new post to his blog today talking about some work that's been done to speed up XDebug's code coverage generation. Changes in the coming 2.2 release have some improvements that make things perform better and put less stress on PHP in the process.

Code coverage tells you how much of your code base is actually being tested by your unit tests. It's a very useful feature, but sadly, it slows down PHP's execution quite a lot. One part of this slowdown is the overhead to record the information internally, but another part is because I have to overload lots of opcodes. (Opcodes are PHP's internal execution units, similar to assembler instructions) They are always overloaded even if code coverage is not used, because it's only safe to overload them for the whole request.

These changes were from a combination of contributions from Taavi Burns and a new ini setting that will allow you to enable or disable the code coverage in XDebug. Benchmarking shows a good amount of time reduction in coverage runs - dropping anywhere from a few seconds to over a minute. He also mentions the idea of "modes", shortcuts to predefined settings for different types of reporting (like "profiling" or "tracing").

On the XPertDeveloper.com blog today there's a new post sharing four handy debugging tools you can use to make finding those elusive problems in your code simpler.

PHP is very well used scripting language in now a days. But PHP does not have any inbuilt debugging tools or extension. But we have some extensions and tools available which serves the debugging purpose of the PHP.

The tools on their list involve both the backend and frontend:

• XDebug
• Zend Debugger
• FirePHP
• PHP Console

In a recent post to his blog Mark Hamlin talks about some of his difficulties in getting XDebug and Netbeans working together from an OSX machine hitting a Ubuntu server.

For the past 18 months working with PHP, i've primarily used alternatives, not out of preference, but because netbeans xdebug integration consistently failed me. It would (might) work with a remote apache, but would not play with scripts executed remotely from the command line. I could be fairly sure my xdebug config was sound as I no problems with MacGDB and PHPStorm whatsoever.

With a little more investigation, he discovered that it was the OSX firewall causing issues. He found that, with a new incoming connection came a confirmation box to approve the connection. This, of course, wasn't passed along to Netbeans so he never saw it. In the end, he set up a reverse SSH tunnel to bypass the firewall completely (command included).

Sometime debugging PHP applications isn't as easy as just pointing your IDE directly at the server and starting to work. Derick Rethans has a new post talking about one such situation, remote debugging with a firewall in between you and the remote machine with XDebug.

The PHP debugging extension Xdebug has "remote" debugging capabilities for single-step debugging PHP applications. This works by setting your favourite IDE into listening mode and instructing Xdebug (with one of the handy browser extensions for example) to initiate debugging. [...] There could however be a firewall in the way that prevents Xdebug connecting directly to your IDE's IP address. That can be because the network you are on employs NAT. [...] In this case, there is no way Xdebug can connect to your IDE's IP address and port. Or is there?

His alternative requires SSH access to the remote machine - building a tunnel from your local machine to the remote server XDebug can use to get around the firewall. He explains the shell command to set up the tunnel and, a more graphical way, through the Putty ssh/telnet client. A quick call to "netstat" can tell you if things are working correctly or not. All that's left then is to point your XDebug to the port on the localhost and you should be good to go on debugging.

Robert Basic has posted a quick hint for Netbeans users on how they can debug two (interlinked) projects at the same time in the same debugger instance.

I'm currently working on some Symfony2 bundles and I have one Netbeans project for the main Symfony2 app and one project for the bundle. [...] The debugger starts for the "main" project, which is the Symfony2 app, but setting breakpoints with Netbeans (y'know, by clicking the line number) for the bundle doesn't really work, as those are in the other project and not in the debugged one, rendering the whole debugging useless.

The fix is pretty simple, if a bit manual - simply place xdebug_break calls in your code anywhere to tell the debugger to stop there. It's not as friendly and automatic as just clicking in the IDE, but it gets the job done. For more information on Xdebug, see their site.

Rob Allen has posted his own guide to getting PHP 5.3 set up on OS X 10.7 Lion, the just-released update for Apple's operating system. It comes with a bundled set of PHP-related tools but you might want to set them up your own way. This is where the guide comes in.

With OS X 10.7, Apple continues to ship PHP 5.3 with PEAR, GD and PDO_MYSQL out of the box. This is how to set it up from a clean install of 10.7.

He goes through each of the pieces of software and talks about where to download the latest from and what configuration steps are needed:

• MySQL
• Apache
• the php.ini
• Xdebug
• PEAR
• PHPUnit (and friends)
• PECL OAuth
• mcrypt