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.

A well-written and informative overview of the request/response communications between client and server over the HTTP protocol.

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…

Your server doesn’t scale. Or, if you have a bigger site, then your servers (plural) don’t scale. They don’t scale ever. Servers in a classical sense are physical devices. They are made of up hardware components, and each of those components has an ability to do some task at some speed, and that’s it. Nothing anywhere gains any sort of capacity in response to the amount of stuff it’s being asked to do. It’s not scaling, and it’s never going to.

For some time now I’ve been wanting to install the Alternative PHP Cache (APC) on the Media Temple GS server upon which this website is hosted. Tantalised by the performance improvements that I’ve read about, APC became my Holy Grail. But I couldn’t get it to install on the GS server, until now.

I’ve documented the steps I used to get APC running here, in case they’re useful to anyone else.

1. Telnet or SSH onto your GS server
2. mkdir /home/#####/data/lib (where “#####” is your Media Temple account number)
3. mkdir /home/#####/data/lib/php
4. wget http://pecl.php.net/get/APC-3.0.19.tgz (at the time of writing, this is the latest stable version - adjust as necessary)
5. tar zxvf APC-3.0.19.tgz (again, adjust as necessary)
6. cd APC-3.0.19
7. phpize5
8. ./configure --enable-apc --enable-apc-mmap --with-apxs2=/usr/sbin/apxs --with-php-config=/usr/local/php-5.2.6-1/bin/php-config
9. make clean
10. make && cp modules/*.so /home/#####/data/lib/php
11. Finally, add the following code to your php.ini file:
    extension_dir = /home/#####/data/lib/php/
extension = apc.so

That’s it. APC should now be installed and you should be able to measure a significant improvement in your PHP script performance.

Via Simon Willison:

An impressive combination. CouchDB can be easily set up in a multi-master configuration, where writes to one master are replicated to the other and vice versa. This makes setting up a reliable CouchDB cluster is as simple as putting two such servers behind a single nginx proxy.

Mark Nottingham tells us about Traffic Server: [via]

A long time ago, the word in high-performance proxy-caching was Inktomi’s Traffic Server. It was so fast it was referred to as being “carrier grade” and this could be said without people smirking, and it was deployed by the likes of AOL, when AOL was still how most people accessed the Internet.

A few years ago, some Yahoo! engineers found that code sitting on a shelf and decided to have a play. What they found was that it was still faster than pretty much every thing else out there. So they started using it, and built a team around it.

Fast forward to today, when the source code for Traffic Server is suddenly available as an Apache Incubator Project.

RED is a framework for testing HTTP resources; it fetches responses, analyses them, and then based upon the responses it may interact with the resource more to see how it behaves. In this manner, it’s very purposefully encouraging RESTfulness.

By building on the open source software and community, we were able to create a top-tier web site with a minimum of cost and effort. The system we ended up with is scalable to huge amounts of traffic. It runs on mostly commodity hardware making it easy to grow when the need arises.