Zend Studio Remote Debugging

  • Posted by Mike Naberezny in PHP

    Remote debugging is one of the most powerful features of Zend Studio, whether used with a webserver on your local machine for development or to profile and troubleshoot a production server.

    To use the remote debugging and profiling features of Studio, the webserver must have the Zend Studio Server component installed. This is a special PHP extension that interfaces with the Zend Engine to provide powerful debugging and inspection capabilities, and provides the socket-based communication back to the Studio client for remote control.

    While the debugger is so powerful that it might seem almost magical at first, the mechanics of its operation are very straightforward. When a URL is selected for debug in the Studio client, it activates your web browser and directs it to load the specified URL, with a special set of GET request variables tacked on the end that cause the Studio Server extension to spring into action. When the page loads, the extension opens a connection back to the Studio client on the debug port. Once the two-way communciation is established, the browser hangs in page-load limbo while the debugging commences.

    Studio knows how to open your browser by the “Browser Activation Command”, and changing this can be useful. This option can be found on the “Preferences” dialog, accessible from “Tools” on the menu bar. On Windows, the Studio will be preconfigured to use Internet Explorer, so its default will be “\Program Files\Internet Explorer\iexplore.exe“. If you’d like to have it open Firefox instead, change the activation command to “\Program Files\Mozilla Firefox\firefox.exe“. The browser activation command is also used when the “Show In Browser” option is invoked from the context menu by right-clicking on the Debug Output pane.

    On UNIX-like operating systems, the default browser activation command will be “mozilla“, a shell script that loads the browser. This can sometimes be a headache for users who do not have this script or the script cannot be found because it is not in the environment PATH. If Studio is having trouble activating your browser, drop to a shell and troubleshoot by trying to enter the same command manually. Once you are able to run it from any arbitrary directory on the shell, Studio should have no trouble activating it.

    There are two small drawbacks that become apparent when using the debugger or profiler on a regular basis. First, it takes a noticeable amount of time to open the browser window with your debug URL, and you must wait on your browser during this time for each page that you debug. Second, depending on your browser, Studio may open a new browser window each time the debugger or profiler is invoked. It’s very easy to find yourself with a pile of useless browser windows open, especially after repeatedly running the profiler. However, this isn’t a drawback in Studio itself, it’s just the browser’s behavior.

    On both Windows and UNIX-like systems, there is a handy trick that eliminates both the startup latency and the extraneous browser windows. You can set your browser activation command to run cURL instead of your browser. On Windows, download the cURL binaries and place them somewhere like “\curl“. Next, change the activation command to “\curl\curl.exe“. Now, Studio will use cURL whenever the debugger or profiler is invoked. Compared to launching the brower, cURL will appear instantaneous, and it will also not open any additional windows. You can now profile as many times as you’d like without ever leaving Studio or closing extra windows. The only downside of this trick is that the “Show In Browser” option will no longer launch the browser, however you can easily change the browser activation command back at any time if you need this capability.

This entry was posted on Sunday, September 11th, 2005 at 9:14 pm and is filed under PHP.