On the Enrise blog Tim de Pater has posted about a different sort of method for debugging your web applications - using a combination of Wireshark and tcpdump to monitor your application's input and output.

Everything is running great, until suddenly the monitoring is yelling, the load on several servers is rising, MySQL queries/second and the memcached commands/second going through the roof, Apache processes are higher than usual, and the website starts giving timeouts. Yes, that sucks. Of course you'll first check everything that comes up in your mind like logs, diskspace, swap, etc. But then you come to a point that you really have to dive into it to find the cause of this sudden problem. There are several ways of doing this. One way I learned the last time we were in this scenario is using tcpdump and Wireshark.

He gives you a brief "getting started" tutorial helping you get things set up - dumping the packets with tcpdump and sifting through the results with Wireshark. His examples are more specific to watching for memcache traffic, but it can easily be applied to more general kinds of requests. Screenshots are also included so you can be sure you're seeing the right kind of results.

On the Silver Lining blog (a MSDN Windows Azure related site), there's a recent post showing how you can enable XDebug on your Azure instance to help with debugging your application.

In this post, I'll cover how to run XDebug (including the profiler) in Windows Azure Web Sites. Enabling XDebug in Windows Azure Web Sites is as simple as enabling an extension. However, enabling an extension for the built-in PHP runtime is slightly different than doing so for a custom PHP runtime. I'll cover both scenarios here.

The post is broken up into two sections - one if you're just using the built-in PHP runtime that's already in the instance and another if you're using a custom one of your own. Changes to the configuration files and some screenshots of where to make the updates are included.

Danne Lundqvist has a new post today showing you how to install and use XDebug with MAMP, the popular all-in-one LAMP package for OS X.

MAMP is a full local server environment including Apache, PHP and MySQL in one package. Anyone feeling at home in *nix systems should feel at home using both OS X and MAMP. [...] As I have helped a few collegues setup Xdebug in MAMP I have discovered that a lot of developers don't do this as they don't know how simple it is. Even seasoned PHP developers use the old echo/die debugging techniques.

He includes all the changes you'll need to make to configuration files and makes a simple script you can use to test out that things are working. As his IDE of choice is PHPStorm, he shows how to set up the remote debugging to work and reply back as the script is executed.

If you've been working with PHP for any length of time, you know that one of the issues the language has shows up when you're trying to debug your applications. Thankfully, as Juan Treminio points out, there's a better way - Xdebug.

Xdebug is a PHP extension that was written and is maintained by Derick Rethans. It provides debugging and profiling capabilities, although I'll be mostly focusing on the debugging aspects in this tutorial. With it you can set a breakpoint and pause the execution of a script to see the state of your application at that exact point, including what variables/objects have been instantiated and what their values are. Xdebug completely replaces the need to litter your code with echo, print_r() or var_dump() calls, and displays information on all variables, not just the one you passed.

He talks some about the current state of IDE/editor support for the tool and shows how to get it installed and your php.ini configured to use it. XDebug make it easy to turn on/off debugging thanks to a handy browser-based switch. He links to a bookmarklet you can use to make it a one-click operation. He includes the setup for using the debugging in PHPStorm, but it's pretty similar for most of the IDEs out there.

Markus Pullmann has a new post to his blog about setting up XDebug in your PHP installation to help you narrow down those elusive issues more quickly.

Debugging locally is a nice improvement to have no debugger at all, but in many situations there is the need to debug on production server, where the application is running on the web. There are different reasons for that, but the most important one for me is, that my local environment / installation is different from the one i have on servers in data center and bugs can be related to the environment.

He walks you through the installation and server-side configuration of XDebug first then shows how to install the Komodo Remote Debugging Client to help with multi-user debugging setups. He mentions setting up the debugging on the client/IDE side, but there's no specific instructions for any particular IDE - just how it works overall.

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.

Karsten Dambekalns has a new post to his blog today about how he was able to get the PHP IDE PHPStorm and XDebug working together to do some debugging in his application.

PhpStorm had it's share of trouble as well [with debugging], but yesterday I experienced a working debug session. Just like that, deep variable inspection and stepping through the code just worked. Today I looked into CLI debugging because Robert needed that for some complicated FLOW3 task. Also works, although it requires one step that should not be needed.

He points out the environment he's using and the two methods/setups he has for debugging - working through the browser and debugging command line scripts with the same tool. Some screenshots are included to help you be sure you're in the right place to change the settings.

One of the more difficult parts of development is debugging. Any tool that can help make your bug finding life simpler can be valuable. Raveren has submitted a new tool he's developed to make outputting your debugging information more useful - Kint.

It's basically a heavily improved var_dump and debug_backtrace version with some advanced behind the scenes action. The features description is in the google code page: http://code.google.com/p/kint/ but the interesting part is that this is the only dump tool, that can display the name of the dumped variable as well as use modifiers on the calling function.

The flow is traced back to its origin class/script and a token parser is used to find where the value was created. You can see a sample of how to use it over on its Google Code page. This also includes screenshots of the output and the configuration values you can set for things like a display path callback and the maximum number of levels to traverse through. You can download the current version here.

On PHPBuilder.com today there's a new article from Jason Gilmore sharing what he calls "four sane solutions" to help you debug your PHP applications better than just an echo or var_dump.

Few tasks are more tedious and frustrating than debugging a Web application. [...] Fortunately, PHP developers have a number of powerful debugging solutions at their disposal. Whether you're merely inspecting array contents or attempting to determine the status of an Ajax-driven POST response, these four solutions are guaranteed to have an immediate impact on your productivity.

His four solutions involve changing the error reporting level on your development environment higher than production to catch issues that might slip through unnoticed, using XDebug, integrating FirePHP and using test-driven development to be sure things work from the outset.

On the Windows IIS blog today Don Raman looks at debugging WinCache (the Windows caching tool with hooks into PHP) with Visual Studio - Basic in the FastCGI version on IIS.

I am planning to write a series of blog post which will be helpful in debugging WINCACHE. This is just the beginning. So please be patient and forgive me if some of the posts sound for novice user. All my post will assume that you are debugging PHP CGI running under IIS using FastCGI. This means using the non thread safe version of PHP/WINCACHE and IIS running PHP files successfully. I believe the same can be applied to thread safe version of WINCACHE/PHP running under Apache but I do not guarantee that.

He mentions his build environment, what you'll need as far as software to debug and the WinCache source to build from. He includes brief instructions on building WinCache (vis Visual Studio) and how to set up the debugging for the PHP CGI. You can then attach the debugger in Visual Studio to the CGI instance and keep a watchful eye on it. You could also use the Windows Debugging Tools to do most of the same work.