In this month’s FREE php|architect issue (available only in PDF), Eric David Benari provides a list of much more specific things to check on the implementation side. It almost sounds like “did you brush your teeth before going to bed?” (I say this in a good way), with things such as having your 404 and 403 pages set up properly, ensuring browser-side caching is specified correctly, serving data and files from RAM not from disk as much as possible, and more. It’s a useful list with good sample code, I recommend it to new web developers as an overview of what aspects of coding for performance deserve attention, and to more experienced coders as a handy cheat sheet.

Now for a bit of a critique. Some of these coding techniques will help a site’s quality a lot, but frankly, if you are testing, then you’ll find out about these issues earlier than at the time of going through the checklist. 

Others will increase your site’s performance by a lot, but if you are benchmarking your app to meet a specific demand, then you’ll know there is a problem (or not) before you look at the checklist.

What really matters is that (a) the way you’ve coded your app and deployed it, it will provide the expected quality of service, and (b) when you need to improve performance, you have a solid idea of how to do so (improve the code, re-code, add hardware resources.) The techniques outlined in Eric’s article are key to both.

So I’m going to stay with my more abstract checklists, along which I have very concrete toolboxes such as the “coding checklist” in Eric’s php|architect article.

Personally, I like to output all the debug messages at the bottom of my html page (structurally speaking, and layout-wise). This way I can see how the output renders for real, and if something looks fishy I have the luxury of a potentially large set of debug messages that I can read through, looking for fishy stuff.

It’s just a glorified ‘echo’ function; but one which lets you decide where to actually output the debug messages in your generated HTML. Or you can think of it as a mini-logging function, that lasts for the time of just one HTTP response; and as a programmer you can do whatever you want with the ‘log’, i.e. output it any way you like.

In fact it is similar to what placeholders do for you within the Zend_View system, i.e. prepare some output but defer when it is actually outputted. In this case, the output is generated from within the controllers, models, and helper classes though, so that’s why I had to, in some sense, duplicate what ZF already provides for views.

Here is a quick tutorial:

First, download the DebugOutput class and rename the file to DebugOutput.php

In a strategic place in your code (for instance the init method of your controller in Zend Framework), include the php file and set the type of debug output you would like (none, inlined within <pre> … </pre>, inlined within <!– … –>, or deferred to your view):

...
public function init()
{
        require_once '..../DebugOutput.php';

	if ( ... /* if in development mode */ ... )
		DebugOutput::setOutputType(DebugOutput::DEFERRED_OUTPUT );
	else
		DebugOutput::setOutputType(DebugOutput::NO_OUTPUT );
	}
...

Then in your code, you call the _debug() function as often as needed:

...

_debug($thisVariable, 'this variable');

...

_debug($thatVariable, 'that variable');

...

Before you rendering engine / view engine / smarty / Zend_View takes over, you make the debug messages available to it in the following fashion (here assuming we are using a Zend Framework Action Controller, i.e. the Zend_Controller_Action class):

...
public function postDispatch()
{
        ...
    	$this->view->debugOutput = DebugOutput::getDeferredOutput();
}
...

And finally, at the bottom of your layout / wrapper / main view (in this case my Zend Framework layout), the debug messages are in an array, available to your rendering engine, and so you can treat them like any other output, for instance like this:

...
<?php if (!empty($this->debugOutput)) { ?>
<div style="background-color: #ffe0e0;
	width: 96%; padding-left: 2%; padding-right: 2%; padding-top: 50px; padding-bottom: 50px; margin-bottm: 100px;
	border: 1px dotted red; overflow: auto; float: none">
<p style="font-weight: bold; color: red; text-align: center">DEBUG INFO</p>
<pre>
<br />
<?php     if (is_array($this->debugOutput))
                    foreach ($this->debugOutput as $debugElement) { ?>
<hr />
<br />
<?= $debugElement['label'] ?>:
<?= print_r($debugElement['value'], true) ?>
<?php         } ?>
</pre>
</div>
<?php     } ?>
</body>
...

I hope someone finds it useful or gets some better ideas from it. If so, please share :-)