The cause was due to some epic temporary files being left behind by ImageMagick:

-rw-------  2.7G Nov  1 10:25 magick-XX27JoRr
-rw-------  3.8G Nov  1 08:49 magick-XX3Ta6P6
-rw-------  1.7G Nov  1 07:22 magick-XX8uxqCS
-rw-------  3.8G Nov  1 08:54 magick-XXzm6nUD

I decided to up the max-execution_time in php.ini as I’d seem some comments that if the processes interacting with imagick are interrupted it can cause the temporary files to not be cleaned up.

max_execution_time = 120

In our case we’re using the imagick library for PHP, but it’s worth bearing in mind that this problem could potentially occur with any other interface to the ImageMagick libaries.

Since doing this, the problem has not re-appeared.

Ed and I have been busy updating the CSS Sprite Generator to improve it’s output quality by using the Imagick library instead of GD and as a result this allows a much tighter control over the output. In the process of doing this we’ve fixed the large majority of all outstanding bugs with the previous version.

A nice addition to this version is the ability to be able to compress the output (assuming it’s png) with the optipng library. This can reduce the image by a significant amount without affecting the output quality so it’s well worth investigating.

The branch on launchpad.net will be updated in the next few days and we welcome any bug reports, comments and suggestions on the site.

We’re currently considering adding an API interface to the site and would be interested to head anyone’s thought on whether they think that would be useful. Clearly for a build script a CLI interface might be something that’s higher up on the wishlist and if that’s you then please let us know.

With the additions to the site there’s a few strings on the site that need to be translated. If you can help us out by contributing those translations or a completely new translation that hasn’t been created yet then please contact us.

This is really handy technique for when you set expires headers to a long way into the future. With headers set in this way files need to have their filenames versioned to force the client to download the latest version of a file. The purpose being that with far futures expires the browser will agressively cache the asset thus minimising the amount of requests for assets.

This template tag for Django uses the same method as Ed’s to provide a version string that’s appended to the filename. The awesome part of this is once configured you can just happily change the file as you need to and the caching is taken care of.

{% load utils %}
<link rel="stylesheet" type="text/css" href="{% version '/static/css/style.css' %}">

The code for this is placed in a utils.py in “project/app/templatetags”

from django import template
register = template.Library()
import os, re        

STATIC_PATH="/path/to/templates/"
version_cache = {}

rx = re.compile(r"^(.*)\.(.*?)$")
def version(path_string):
    try:
        if path_string in version_cache:
            mtime = version_cache[path_string]
        else:
            mtime = os.path.getmtime('%s%s' % (STATIC_PATH, path_string,))
            version_cache[path_string] = mtime

        return rx.sub(r"\1.%d.\2" % mtime, path_string)
    except:
        return path_string 

register.simple_tag(version) 

As Brad has pointed out in the comments below the original query string method used will not be cached by UAs following the http spec. The output will now look like the following:

/static/css/style.css?v=1207433992
/static/css/style.1207433992.css

In addition a mod_rewrite rule is required to map the versioned file to the original.

RewriteRule ^/static/(.*?)\.[0-9]+\.(css|js|jpe?g|gif|png) /static/$1\.$2 [L]

The .htaccess performance hit

If .htaccess files are allowed (through the AllowOverride directive) then apache will look for .htaccess files on every request. In addition apache has to look up the directory tree to see if there are further .htaccess files in locations above the location the file is requested from so that it can tell which directives have precedence. For example: if you request a file from /foo/bar, apache has to look for /foo/bar/.htaccess, /foo/.htaccess and /.htaccess and that’s even if there are no .htaccess files present in any of those locations! Once a .htaccess file is found it has to be parsed and don’t forget all of this has to happen for every request!!

As there’s nothing in a .htaccess file that can’t be achieved in your httpd.conf (or files included by httpd.conf) it makes sense to move existing .htaccess rules into your apache conf using a Directory or Location directive as appropriate.

Restarting apache without dropping users

One other reason why .htaccess are seen as a convenience is that they don’t require apache to be restarted after configuration changes. However if you restart apache with “apachectl graceful” you only force the parent process to re-read the apache configuration files and the children to restart when they’re not doing anything and as a result no end users are suddenly dropped.

Finding all of the .htaccess files on your system

Simply drop on to your terminal and change directory to where you site files are located and run: find . -name *.htaccess -print. This should provide output that shows the location of all of the .htaccess files so you can go through one by one and move them to into httpd.conf or a file included by httpd.conf.