When you are working on a web site or web application, something that little thought is spared for at development time all too often is it’s performance. You need to know where your bottlenecks are and what the costs of each architectural and implementation choice you make are. You should routinely profile your application’s core functions to see how they behave. How do we do this? You could put little timers into the code and log timings to see how things work, or you could use XDebug.

XDebug is a PHP extension that provides a number of critical features to developers. It supports step through debugging (assuming your code editor can hook into it) and it supports profiling of your scripts. This gives you a detailed breakdown of every command executed in your application, how many times it was executed and what it cost.

This is invaluable when tracing your performance work. You can identify exactly which routines are costing you too much. It can give valuable insight into the performance landscape of your software. So I’m going to hook it up into my development environment on it’s USB key.

Firstly, pop over to the XDebug site and download the relevant version for your PHP version. I downloaded the Windows Binary of 2.0RC4 for PHP 5.2.1+. XDebug is a “Zend Extension”, it’s not a standard PHP Extension, it extends the Zend Engine that powers PHP. This changes how we configure it in php.ini and means it doesn’t have to go on the extensions folder of your PHP install. But, I keep it there for consistency. Once placed in that file you need to edit your php.ini, the commands can go anywhere in the file, but, I placed them after the PHP Extension loading commands, again for consistency:

zend_extension_ts=/development/php/ext/php_xdebug-2.0.0rc4-5.2.1.dll

Note that this is loaded with the zend_extension_ts command instead of the extension command (the ts denotes Thread Safe mode) . Also note that we specify the full path to the extension. The zend_extension_ts (and other zend_extension commands) need the full path as they don’t pay attention to our extension directory command.

Once this is done, go to your PHPInfo() test page and check, you should have XDebug information included:

Ok so far so good. If you have a page which currently throws a php error, go check it now. You’ll notice that just having XDebug installed gives you much more information. XDebug makes developing easier just by being there.

Now, we’re mainly going to use it to profile performance of our applications and third party libraries, so we need to enable profiling, this is done with a couple of new entries in php.ini. I placed them just after my command to load the extension so it’s all in one place:

xdebug.profiler_enable = 1
xdebug.profiler_output_dir=/development/

Now restart Apache and hit your PHPInfo() page. In the development folder on your USB Key you will have some files called cachegrind.out.[some number]. This is the profiling information in it’s raw form and of no use to you on it’s own.

You need a cachegrind analysis program. I use Wincachegrind as I’m on windows. You can use this to open up the cachegrind file and see what took what time. Visit yourPHPInfo() page, pick up the cachegrind output and take a look. You can see a lot of detail.

I don’t propose to detail how to use Wincachegrind and do a full analysis, a bit of poking should show you what’s going on. But, I’ll be using XDebug and WinCacheGrind to get under the covers of some third party libraries I’m considering for use in the development of Multiblog, so we’ll see more information then.

Popularity: 30% [?]

We now have Apache and PHP on a USB Key. We need a database, so we’re going for MySQL. Unfortunately, this step is much like getting Apache working. We have to download the installer from the MySQL site and install it. Then we take a copy of the installed directory and copy it onto the USB key and uninstall from the host machine.

Once we have this copy, we need to create a batch file to launch it and test it. This removes the need for a custom my.ini with path fixes, because we can pass those items on the command line. My batch file contains:

\development\mysql\bin\mysqld-nt.exe --basedir=/development/mysql --datadir=/development/mysql/data --port=3306 --console --standalone

We should now have a working Apache, PHP and MySQL, and we just need to tie it all together. To do this, I’m going back to the firepages method. I have a start.php script that contains the following:

<?php
echo "starting MySQL ....\n";
pclose(
    popen(
        'start \development\mysql\bin\mysqld-nt.exe --basedir=/development/mysql --datadir=/development/mysql/data --port=3306 --console --standalone'
        ,'r' )
    );
echo "starting apache....\n";
flush();
pclose(popen('start \development\apache\bin\apache.exe','r'));
flush();
sleep(5);
echo 'opening localhost';
exec( 'start http://localhost:8080/');
?>

And a start.bat file that launches PHP in an appropriate fashion to finish that off:

/development/php/php.exe -c /development/php/php.ini -f /development/start.php

There we go. All done. Of course, this could be acheived by downloading XAMPP (Lite), however, this way we know how our environment hangs together and can easily upgrade and extend it.

At a later date, I’ll be getting PEAR working, installing XDebug and getting a PHP4 instance in here. But for now, we have a sufficient development environment to get on with things.

Popularity: 13% [?]

So now we have an Apache instance on a USB Key. Great. Can’t do much with it, other than brochureware, so our next step is to get PHP working.

Fortunately, the nice people at PHP provide Windows Binaries in a zip file. No messing with installers and then re-copying everything. Just go and grab the latest stable Windows Binary Zip of PHP from their downloads section. This can then just be extracted into /development/php.

I’ve gone for PHP5, later, I’ll show you a quick change to the portable environment I have that enables me to test Geeklog on PHP4 as well. (I use my portable environment for the stuff I do to Geeklog too, and that needs to support older PHP versions).

We have to edit a couple of files to get this to work on the key. Firstly, we need to configure the php.ini file to support our environment. Again, the first step here is to change paths to relative ones. Simple job of finding all the paths and editing them. Boring hey?

We then have to edit the httpd.conf file again to get it to load PHP:

LoadModule php5_module "/development/php/php5apache2.dll"  

addtype application/x-httpd-php .php .php4 .php5 .php3 .htm .inc .fire  

PHPIniDir "/development/php/php.ini"

Once that’s done, we can shut down and re-start. We also need a test php file to be sure whether or not the PHP instance is working, this is done by creating a new file called phpinfo.php, dropping it onto our web root and putting the following code into it:

<?php
phpinfo();
?>

We then visit that url in our browser: http://localhost:8080/phpinfo.php and should see a nice page telling us all about how our PHP instance is configured.

We don’t really want to leave things there, there are a number of further configuration options that it’s worth getting out of the way now, since we’re tuning for development not production and the sample distributed php.ini is a sensible startign point for a production server.

The main thing we need to turn back on is error reporting to screen and log. Both of runtime and startup errors. As we add and remove extensions and as we code, we need to know in real time that errors are happening:

display_errors = on
display_startup_errors = on
log_errors = on

The magic_quotes_gpc directive is an interesting one. It’s there to protect the not so great programmers from common attack vectors. I turn it off, always, and make sure that I work round the case where it’s on. This means I have to turn it on to test. But I keep it off for development. Geeklog (an open source project to which I contribute) works with it on or off. I write my applications to work with it in either state, but, I prefer to have it off, because it saves resource and I trust my code to protect my code better than the magic_quotes_gpc setting.

If you are not sure whether you want it on or off, find out what your production host has set, and use that.

With PHP5 you need to ensure that the mysql extension is loaded (remove the ; which has commented it out), and in preparation for our mobile MySQL on USB instance, we’re going to change the default MySQL port in the MySQL area of the ini file.

extension=php_mysql.dll

and

mysql.default_port = 3306

And that should be it, a fully working, development adjusted PHP5 in Apache instance set up and ready to go.

Popularity: 22% [?]

Of course, the first part of your AMP instance to get working is the Apache part. A is the first letter of the alphabet, and you need Apache working before you can introduce PHP. And you may as well have AP working before trying to get MySQL working, since MySQL is there for your PHP application to talk to.

The problem I found with Apache was finding a reliable, trustworthy build of Apache for Windows in a non-installer format. I gave up in the end and grabbed the latest stable release of the 2.0.x line for Windows from the Apache downloads site here. You then have to run the installer and install it on a spare windows machine.

Once you have installed it, grab the contents of your install folder (Typically c:\program files\Apache Group\Apache\ or similar) and stick it into a folder on your USB Key. I went for \development\apache containing the contents of my Apache folder.

Once you’ve done this, you need to make some changes to your httpd.conf file. This can be found in the apache\config folder. Edit it in any text editor.

The main complication of using a USB key is that when you stick it in one PC, it will likely have a different drive letter assigned to it when you stick it in another PC. So, we need to make sure all paths are relative.

Now, firepages specifies using \\pdrive\\apache, I found this didn’t work. I used /development/apache/ and this worked fine. In fact, in all places I used Unix style path separators over Windows style path separators. And it all just worked.

In my httpd.conf I specified a number of virtual directories for each application I was working on, I’ll come to them when we first set up a test environment for evaluating software libraries. However, I followed Firepages example and set up a /development/applications/www directory for the server root. In there I maintain an index.html that lists all the things I have to access and works as a start page for me.

The other vital step, is to change the Listen directive to make Apache run on an obscure port. Because the machine you’re using might already have Apache or IIS running on port 80. I usually go for 8080.

Listen 8080

So, once we have Apache copied to our USB key, replaced all the absolute paths with relative Unix style paths to the USB key folders, changed the port Apache will run on and dropped a test index.html into the /development/applications/www folder, we can uninstall Apache from the host machine and leave it clean again.

Now we need to start Apache. I created a temporary start.bat that contained some basic stuff to do this:

/development/apache/bin/apache.exe

Once we run that up, we should have an Apache instance on port 8080. Just point a web browser at it. Congratulations, it’s a little baby portable Apache!

Popularity: 13% [?]

It doesn’t matter what you are doing, whether that is managing a web site that you run using an application such as Wordpress or writing your own application from scratch. You need a development environment. To run this site, I have my main webhosting with an installation of Wordpress. My Wordpress installation has a custom theme and I’ve installed a selection of plugins to get the functionality I require.

I did not prepare this work on my live webserver.

Since I set this site live, with Wordpress 2.0.5, two security releases (2.0.6 and 2.0.7) were released. Then Wordpress 2.1 was released, followed by three security updates. My site has now run six versions of code, it’s fully up to 2.1.3 (2.1.1 was compromised on the Wordpress site before I downloaded it and they advanced to 2.1.2 to avoid confusion).

But, when I did the upgrade work, I didn’t do it on the live site.

Once you have a site live with some software, you need to perform the upgrade on a copy of that site and refine the process so that when you do come to take your site down for the upgrade process it is a simple exercise that results in your site being live once more as soon as possible. Not leaving your blog down for days.

When you’re working on software, you want full control of the environment so you can debug and experiment to identify what the problems you are having are. You have to have a development environment.

Now, most web hosting is LAMP. Linux, Apache, MySQL and PHP. For things like Wordpress, Geeklog and the majority of web development, LAMP is the most available and most used platform. How do you go about having a LAMP environment to develop on? I would strongly suggest that you don’t want to use any hosting provider as your development environment. You may want a staging host, a subdomain that you perform the upgrade on before copying to your live environment. But the trial and error troubleshooting and testing phase should be on your Development Environment.

Now, if you’re not the kind of person who has a Linux box to hand that they can use for this, fear not, Apache runs anywhere, as does PHP and MySQL. You could install them on your Windows Vista/XP/2000/98/95 box (or even your Mac) and have an environment there. There are even bundled installers that give you the AMP portion all running in a few mouse-clicks.

But, I don’t use one machine. I have two laptops at home, and I could be on either, depending on what else I need to do and whether or not my wife wants to play games. I have a machine at work that I don’t want to have a copy of my development environment permanently set up on, and I don’t want the headache of keeping three environments in synch.

So, I had a bit of a Google to try and find a solution for a portable development environment. I’ve seen portableapps.com’s [1] available end user software and started looking for options for AMP development that can be extended to include Python, Ruby and other languages. I found a good article at firepages that was my starting point.

Since I first created my portable environment, portableapps.com released a portable XAMPP which would have saved me the effort. If you just need an AMP instance, I would investigate that. However; I want to understand my environment, know how it hangs together, feel confident playing with it and be installing Ruby and so forth. It’s also far more interesting to me, to build my own. Sad, but true.

I’m going to write a few articles on getting your AMP instance set up on your USB key, as I’ll need that environment to talk about evaluating software libraries and starting development. So this is going to briefly interrupt the flow of the Multiblog articles.

I decided on a simple structure for me USB key, I have a development folder in the root. This contains an Apache folder, a PHP folder, a MySQL folder and an Applications folder. Also in the root I have a Tools folder, containing installers for tools I use all the time, and a Downloads folder where I place the tar balls of things like Wordpress when I download them.

I then set out to start installing.

Popularity: 14% [?]