A nice introduction to dynamic page caching complete with source code.

I became aware of an annoying little glitch on the Urban Mainframe yesterday. It seems that WordPress, on which this site is running, doesn’t handle the URL http://example.com/index.html on an unmodified install (I’ve confirmed this on a handful of other WordPress sites). This is significant because index.html is a special file on many web-servers, often being the “home” page of a directory on the server. Without special handling, a request for index.html on a WordPress installation generates a 404 (file not found) error — which is obviously something we don’t want our visitors to be presented with.

In my case the impact of the glitch was magnified because I employ a quite aggressive caching policy on this website — and yesterday an unlikely combination of factors resulted in my 404 error page replacing my home page for a complete cache cycle. It went something like this:

• cached “home” page expires
• next “home” page request is for http://urbanmainframe.com/index.html
• index.html file request results in a 404 error
• 404 error page is cached
• all subsequent requests for http://urbanmainframe.com/ — and other “home” page URLs — return the cached 404 error page until the cache is next invalidated

Quite a serious glitch then!

There are two things that shouldn’t have happened here.

1. Requests for index.html should not result in 404 errors.
2. Error pages should never be cached.

I resolved the first issue by adding the following snippet of code to the very beginning of the 404.php file in my WordPress theme:

<?php
if ($_SERVER['REQUEST_URI'] == '/index.html') { header("Location: http://urbanmainframe.com/"); exit; }
?>

For the second issue I’ve filed a bug report with the authors of W3 Total Cache, which is the caching system I use here on the Urban Mainframe.

Apple’s launch of the iPad didn’t really rock my world. But, within the iPad presentation, there was a little something that got my spine tingling: Apple revealed that the iPad is powered by a heretofore unknown CPU - the A4.

To me this is much bigger news than the iPad itself. This is an Apple-developed CPU, which I think is a first for the company. Apple describe the A4 as a “1GHz custom-designed, high-performance, low-power system-on-a-chip.” Early hands-on reports of the iPad seem to support this. One thing that is now well documented is that the iPad is very fast. Apple also claim run times of up to 10 hours and a standby time of up to 1 month for the iPad, so it’s clear that the A4 is very power-efficient.

So what do we know or can reasonably assume about the A4?

We know it runs at 1GHz which, in the case of the iPad, results in a respectable performance. We know that, as a “system on a chip,” it contains both a CPU (initial suspect is an ARM Cortex-A9 MPCore) and a GPU (most likely a PowerVR SGX series 5 - the ARM Mali has also been suggested). So it’s multi-core capable and has a high-performance FPU. It’s also OpenGL capable.

It’s probably reasonable to anticipate that this chip, or its derivatives, will pop up in future iPods, iPhones and perhaps the Apple TV — along with any further mobile devices that Apple conceives — as well as the iPad and its future revisions.

I don’t think that the processor, at least in this form, will appear in Apple’s desktops or laptops — and it’s not needed there either.

What’s really exciting about the A4 is that it’s a first attempt - yet it competes very favourably with the established mobile CPUs from the likes of Qualcomm, et al.

I’ll bet the launch of the iPad has caused concern in the boardrooms of quite a few companies. It’s going to be very interesting to see how this plays out.

Using the command line tool opensnoop you can track any Mac application’s (or system process’) usage of the file system. This is a very handy tool for administrators and troubleshooting! The simplest way to use it is as follows:

sudo opensnoop -n Safari


You can also track a specific file, and what is accessing it, like so:

sudo opensnoop -f /etc/hosts


Tracking a specific process is as simple as just specifying the process id:

sudo opensnoop -p PID


opensnoop will keep tracking the file until the process itself is ended, so just hit Control-C in the Terminal to stop opensnoop from running. In case you’re wondering, opensnoop is based on DTrace, a popular UNIX tool.

[via]

What really set the original Amiga 1000 apart from the comparatively weak computers of the day, aside from its light-weight, multitasking operating system, was the set of custom chips that allowed the machine to deliver stunning graphics, full-screen animation, and high-quality, sampled, stereo audio — firsts, on all fronts. Today, every PC has “custom chips” driving their graphics and audio. Any modern Amiga utilizes such technologies as a matter of course. What sets the AmigaOne X1000 apart from the rest is its use of customizable co-processors.

Gearman provides a generic application framework to farm out work to other machines or processes that are better suited to do the work. It allows you to do work in parallel, to load-balance processing, and to call functions between languages. It can be used in a variety of applications, from high-availability web sites to the transport of database replication events. In other words, it is the nervous system for how distributed processing communicates.

Sounds awesome. I’ve got to make some time to experiment with this.

Preloading images is a great way to improve the user experience. When images are preloaded in the browser, the visitor can surf around your site and enjoy faster loading times. This is especially beneficial for photo galleries and other image-heavy sites where you want to deliver the goods as quickly and seamlessly as possible.

Fortunately, there are ways to get scripts to download without blocking any other resources in the page, even in older browsers. Unfortunately, it’s up to the web developer to do the heavy lifting.

There are six main techniques for downloading scripts without blocking:

• XHR Eval - Download the script via XHR and eval() the responseText.
• XHR Injection - Download the script via XHR and inject it into the page by creating a script element and setting its text property to the responseText.
• Script in Iframe - Wrap your script in an HTML page and download it as an iframe.
• Script DOM Element - Create a script element and set its src property to the script’s URL.
• Script Defer - Add the script tag’s defer attribute. This used to only work in IE, but is now in Firefox 3.1.
• document.write Script Tag - Write the <script src=””> HTML into the page using document.write. This only loads script without blocking in IE.

Ah now this is pure gold, 21 things to keep in mind when coding for MySQL. Most of these I knew but it was good to be reminded. Some of them are entirely new to me though:

• Use ENUM over VARCHAR: ENUM type columns are very fast and compact. Internally they are stored like TINYINT, yet they can contain and display string values.
• Store IP Addresses as UNSIGNED INT: Many programmers will create a VARCHAR(15) field without realizing they can actually store IP addresses as integer values. With an INT you go down to only 4 bytes of space, and have a fixed size field instead.
• Do Not ORDER BY RAND(): This is one of those tricks that sound cool at first, and many rookie programmers fall for this trap. You may not realize what kind of terrible bottleneck you can create once you start using this in your queries.

Priceless information. I’ll be referring back to this list over and over again.

A long time ago, in a galaxy far, far away… oh sorry, wrong script. I’ll start over. In the dim and distant past, I wrote about my efforts to eke a little bit more performance out of the WordPress installation that this glorious website runs upon. What I’d done was fairly basic: content compression, reduced page weights, database tuning… the usual stuff.

I also described how I’d failed to get WP Super Cache working and wrote that I was investigating PHP accelerators. Yet, despite my endeavours, the website’s performance continued to be, well, pitiful. Some time later I managed to get WP Super Cache working and things improved, but were still disappointing to me.

I come from a mod_perl background and one of mod_perl’s strengths is the speed at which it can run its applications. The PHP app’s that I now find myself working with just can’t compete. I believed that I’d just have to accept that the performance goals I was aiming for weren’t achievable.

However, I was recently forced to reconsider my position when I was contracted to build a website on top of the Zend Framework — because, despite being written entirely in PHP, nursesstore.co.uk turned out to be very fast.

Suddenly, I knew that it was possible to build fast PHP applications. So I turned my attention, once again, to the speed-deficient Urban Mainframe with the fire of the true zealot burning in my eyes.

Continue Reading…