Statification

On a sample webserver, create a directory called statify. Inside, install a .htaccess file defining a 404 handler. The 404 handler is a PHP page, and to make things a bit easier on the brain should not be located inside /statify. The 404 handler must be able to create files inside /statify, so that directory has to be writeable by the webserver, for example by setting it to mode 01777.



To better understand what is going on create a statify.php like this:



Here is the result:



The interesting variables are $_SERVER["DOCUMENT_ROOT"] and $_SERVER["REQUEST_URI"]: The DOCUMENT_ROOT is needed to find the directory to write the generated content to, and the basename of the REQUEST_URI is the basename of the file to generate. It may be tempting to just write to $_SERVER['DOCUMENT_ROOT']/$_SERVER['REQUEST_URI'], but I just know that you are not that naive.

A clean implementation will reject everything that is not asking for a PNG, and is also cleaning up the REQUEST_URI before using it to construct the filename:



Painting the image is straightforward:



This now has to be written into the proper location as a file, and then served to the end user.



After requesting a few test images, the /statify directory might look like this:



Looking at the request log one can see what is going on (Yes, I am in Norway right now :-):



The first request 404'ed and served up the 1784 bytes of blabla.png, writing the file. That was at 19:23. The second request 200'ed, and served up the same 1784 bytes, but this time using the fast path of the web server serving static content.

That is precisely what we wanted.

A similar, but different approach was taken in PEARs XML_Transformer. In XML_Transformer, XML Input is being transformed into XML (or XHTML) output. So you get to make up your fantasy XML tags and tie PHP code to them that transforms these into useable XHTML. One particularly nice tag that is provided with XML_Transformer is the <img:gtext&gr; tag, which lets you write text which is then transformed into a regular <img> tag and an image to match.



Here, a 404 handler is not used. Instead the image file is generated with a random name, which is then delivered as the gtext transformation result, an IMG tag. A second access to the same gtext tag will generate the same img tag with the same filename, and so the rendering of gtext tags content into an image will not happen twice. Note that here the page is not completely statified: The XML_Transformer will still be called to generate XHTML, but the images generated by the XML_Transformer are reuseable static files on the second and all subsequent calls.

The image filename is generated from all attributes of the gtext tag and the content of the tag. To make the filename safe to use in a filesystem and to keep it short, it is in fact the MD5 output of that string. And because XML attributes have no order, the attributes of the tag have to be sorted before they can be MD5'ed.



This will ensure that different filenames are being generated when any attribute of the gtext tag or the tags content change. It is sufficient to monitor the size of the cache directory: If the size crosses an upper threshold, delete the oldest file from the directory in a loop until the size falls below a lower threshold, implementing a LRU scheme and minimizing the actual image generation work being done in the language.

Statification is not limited to images, though, but can be applied to anything: Entire text pages or boxed page fragments generated from MySQL as well as any other thing that requires a lot of effort to generate. PEAR does provide a really nice little wrapper class Cache Lite to handle these cases in PHP.

To use Cache_Lite, you basically create an object instance and then try to $data = $cache->get($id) an id. If this is successful, you may to stuff with $data, otherwise you have to calculate $data and at the end of the calculation, you $cache->save($data). On the second call to the same id, $data will then be returned and no calculation needs to be done.

Cache_Lite has even more useful subclasses. Cache_Lite_Output for example wraps any segment of PHP using the output buffer. Thus, you can use it to statify any PHP page or subsection of a PHP page.



Cache_Lite can also wrap and cache function calls: Using the Cache_Lite_Function class it should be possible to write an implementation of Ackermann that actually terminates with results for many cases that otherwise overflow a systems stack.

The biggest drawback of Cache_Lite is currently that is takes away a lot of work from the system, but unlike 404 statification does not completely shortcut the scripting from the server, so the servers fast path is not being used.