The test was run using the following commands on ten 100MB files generated by urandom, on an Intel Atom D510 with a 7200rpm disk.

# time bzip2 -1 *
# time bunzip2 *
# time ls | parallel bzip2 -1
# time ls | parallel bunzip2
# time gzip --fast *
# time gunzip *
# time ls | parallel gzip --fast
# time ls | parallel gunzip
# time lzop -U --fast *
# time lzop -U -x *
# time ls | parallel lzop -U --fast
# time ls | parallel lzop -U -x

Results:

In this test, under these conditions, lzop is the clear winner.

Compression benchmark is a post from Fredrik Poller

World IPv6 Launch is a post from Fredrik Poller

Yesterday, Rackspace announced their new Cloud DNS service. This is clearly(?) a response to Amazon’s Route53 release a while back. With one big difference; Rackspace Cloud DNS is free (in combination with other Rackspace Cloud Products), whereas Route53 is not.

I’ll admit I haven’t tried the Rackspace service (yet), but here’s a quick comparison table anyway. Some questions (about branding and distribution) I couldn’t find answered on the Rackspace information page, so I used the support chat.

* Neither Amazon nor Rackspace has a management interface for the DNS services. DNS30 is however availible for Route53.
** 19 locations on 3 continents
*** 3 locations on 2 continents (see comment below)
**** Alias records are used to map resource record sets in your hosted zone to Elastic Load Balancing instances.

If the choice only stood between Route53 and Rackspace I think I’d go with Rackspace, just because of the IPv6 connectivity. But other providers should also be considered, Zerigo for example has an excellent DNS service.

Update: After the comment below by Daniel Morris at Rackspace I tried to contact the chat support again to get the information about the edge locations. Here’s the response:

Agent: I’m sorry but I am not positive I would recommend contacting the support team at 1-877-934-0407 or 0800 054 6345 | +44 20 8734 4345
Agent: I’m sorry for any inconvenience this has caused
Agent: have a great day

Not very impressed wit this fanatical support, to be honest.

AWS Route53 vs Rackspace Cloud DNS is a post from Fredrik Poller

The test was done on a 512MB rackspace instance, running Ubuntu 10.10. With the following packages installed with default configuration: libapache2-mod-php5 mysql-server php5-mysql. Benchmark was done with ab, doing 10 000 requests to the front page, over 10 concurrent connections.

This is the result, in requests delivered per second:

Clearly, speed isn’t that much improved with the release of 3.2. However, this benchmark only tested the front page with the sample post.

Quick and dirty WordPress speed comparison is a post from Fredrik Poller

#!/usr/bin/perl
 
use strict;
use warnings;
 
use Net::CIDR::Lite;
 
# Get files
my $infile  = $ARGV[0];
my $outfile = $ARGV[1];
 
# Open infile for reading
open(FILE, '<', $infile);
 
# Define iplist array
my %iplist;
 
# Loop infile
while(<FILE>) {
        # Set start, end and country variables
        my @line = split(/\"/, $_);
        my $start_ip = $line[1];
        my $end_ip   = $line[3];
        my $country  = $line[9];
 
        # Use the CIDR class to get networks in the range
        my $cidr = Net::CIDR::Lite->new;
        $cidr->add_range("$start_ip-$end_ip");
        my @networks = $cidr->list;
 
        # Put networks in the iplist array
        foreach(@networks) {
                $iplist{$country} .= "\t" . $_ . ';' . "\n";
        }
}
 
# Close the infile file handle
close FILE;
 
# Open outfile for writing
open(FILE, '>', $outfile);
 
# Loop iplist array
foreach my $country (sort keys %iplist) {
        # Write to outfile
        print FILE 'acl "' . $country . '" {' . "\n";
        print FILE $iplist{$country};
        print FILE '};' . "\n";
}
 
# Close the outfile file handle
close FILE;
 
# We're done

Simple usage:

$ ./geoip.pl GeoIPCountryWhois.csv countries.acl

You’ll need the Net::CIDR::Lite extension for Perl, in Debian/Ubuntu the package is called libnet-cidr-lite-perl.

GeoIP CSV to Bind ACL is a post from Fredrik Poller

The test was done on a 512MB rackspace instance, running Ubuntu 10.10. With the following packages installed with default configuration: libapache2-mod-php5 mysql-server php5-mysql. Benchmark was done with ab, doing 10 000 requests to the front page, over 10 concurrent connections. Both blogs used the Twenty Ten 1.2 theme, and the supplied sample post.

This is the result, in requests delivered per second:

As you can see, things aren’t any faster, yet. But this is still a beta, and i only tested the performance of the front page, nothing else. I also tried the Twenty Eleven theme, but that wasn’t any faster.

WordPress 3.2 beta 1 speedtest is a post from Fredrik Poller

To use Notifo with Nagios there’s two solutions. The first (and the easiest one), is to configure Nagios to send emails to the email address provided by Notify. The other (and the one described here), is to configure Nagios to execute a scripts that sends a POST request to the Notifo API.

I’ll asume that you have a working Nagios setup, a Notify account, the client installed and configured on your phone, and your Notifo API key handy.

Lets start by adding two commands to the Nagios configuration, depending on your setup this can be done in many places. If there’s a commands.cfg file present that’s probably a good place to put it. Open the file and add the following:

define command {
    command_name    notify-host-by-notifo
    command_line    /usr/bin/perl /usr/local/bin/notifo -username="$_CONTACTNOTIFO_USERNAME$" -apikey="$_CONTACTNOTIFO_APIKEY$" -title="Host" -msg="$HOSTNAME$ $HOSTSTATE$ '$HOSTOUTPUT$'"
}

define command {
    command_name    notify-service-by-notifo
    command_line    /usr/bin/perl /usr/local/bin/notifo -username="$_CONTACTNOTIFO_USERNAME$" -apikey="$_CONTACTNOTIFO_APIKEY$" -title="Service" -msg="$HOSTNAME$ $SERVICEDESC$ $SERVICESTATE$ '$SERVICEOUTPUT$'"
}

Then find the file containing the contact you want to use, and add the Notify username and password. Also modify the host and service notification commands. The result should be something like this:

define contact {
    contact_name                    admin
    alias                           Administrator
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,r
    service_notification_commands   notify-service-by-email,notify-service-by-notifo
    host_notification_commands      notify-host-by-email,notify-host-by-notifo
    email                           <EMAIL>
    _notifo_username                <USERNAME>
    _notifo_apikey                  <APIKEY>
}

Of course, make sure you use your own name, email and Notifo credentials.

Then save the following script as /usr/local/bin/notifo (or whatever you want, make sure it’s the same path as the one configured above).

#!/usr/bin/perl
 
use strict;
use warnings;
 
use HTTP::Request::Common qw(POST);
use LWP::UserAgent;
use Getopt::Long;
 
# Get options
my %options = ();
GetOptions(\%options, 'username=s', 'apikey=s', 'title=s', 'msg=s');
 
# URL encode msg
$options{'msg'} =~ s/([^A-Za-z0-9])/sprintf("%%%02X", ord($1))/seg;
 
# The request
my $req = POST 'https://api.notifo.com/v1/send_notification',
	[ 'msg' => $options{'msg'}, 'label' => 'Nagios', 'title' => $options{'title'} ];
 
# Add auth to the request
$req->authorization_basic($options{'username'}, $options{'apikey'});
 
# Do it
my $ua = LWP::UserAgent->new;
$ua->request($req);

Make the script executable.

# chmod +x /usr/local/bin/notifo

Try the script to make sure it works.

# /usr/bin/perl /usr/local/bin/notifo -username=<USERNAME> -apikey=<APIKEY> -title=Test -msg=Test

Reload Nagios, depending on your configuration this can be done in many ways, usually it’s the following command.

# /etc/init.d/nagios3 restart

That’s it.

Now, when something goes wrong, you’ll be notified immediately.

Using Notifo with Nagios is a post from Fredrik Poller

When using a mobile theme plugin, WPtouch in my case, the serving of static files (WP Super Cache does that in rewrite mode) needs to be disabled for mobile requests. Otherwise you could end up with static files (containing your standard theme) being served to mobile users.

WP Super Cache also needs to be configured with Mobile device support to prevent mobile visitors from trigger static files to be generated. So start by enable that feature in the advanced settings for WP Super Cache.

Then change the Nginx rewrite rules to the following.

# Return existing files
if (-f $request_filename) {
        break;
}

set $supercache_file '';
set $supercache_uri $request_uri;

if ($request_method = POST) {
        set $supercache_uri '';
}

# Bypass cache for requests containing a query string
if ($query_string) {
        set $supercache_uri '';
}

if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) {
        set $supercache_uri '';
}

# Bypass cache for mobile users
if ($http_user_agent ~* "(Android|CUPCAKE|bada|blackberry 9800|blackberry9500|blackberry9520|blackberry9530|blackberry9550|dream|iPhone|iPod|incognito|s8000|webOS|webmate)") {
        set $supercache_uri '';
}

# Specify the cache file
if ($supercache_uri ~ ^(.+)$) {
        set $supercache_file /wp-content/cache/supercache/$http_host/$1index.html;
}

# Serve the cache file, if it exists
if (-f $document_root$supercache_file) {
        rewrite ^(.*)$ $supercache_file break;
}

# Everything else goes to index.php
if (!-e $request_filename) {
        rewrite . /index.php last;
}

The user agents listed above are the same ones WPtouch sends the mobile theme to. If you change the settings in WPtouch, change the rewrite rules as well.

Reload Nginx.

Install, enable and configure the WPtouch plugin, and that should be it. I’ve been using this setup for about a month now without any problems, let me know if you run into something.

Nginx, WordPress, WP Super Cache and Mobile Theme is a post from Fredrik Poller

CloudFront has support for origin pull (this way, there’s no need to sync files, they’re fetched on demand from the web server). Configuring this can be a bit tricky, since the AWS web interface only supports AWS S3 buckets to be configured as backends.

To get a distribution with origin pull up and running we need to do it manually. I’m assuming you’re working on some kind of unix/linux system (OS X for example). First of all, you need an AWS account with CloudFront. If you don’t already have one, get it here.

Create a file named .aws-secrets containing your AWS Access Keys (these can be found in the AWS Portal under Account -> Security Credentials), in the following format.

%awsSecretAccessKeys = (
    "my-aws-account" => {
        id => "ID goes here",
        key => "Key goes here",
    },
);

Create a XML file containing the settings of the new distribution, name it cf.xml.

<DistributionConfig xmlns="http://cloudfront.amazonaws.com/doc/2010-11-01/">
<CustomOrigin>
    <DNSName>example.com</DNSName>
    <HTTPPort>80</HTTPPort>
    <OriginProtocolPolicy>http-only</OriginProtocolPolicy>
</CustomOrigin>
<CallerReference>1234</CallerReference>
<CNAME>cdn.example.com</CNAME>
<Comment/>
<Enabled>true</Enabled>
<DefaultRootObject>index.php</DefaultRootObject>
</DistributionConfig>

Replace example.com with your domain. CNAMES can also be added and changed later via the AWS Management Console.

Download the cfcurl.pl script.

Execute the following command.

cfcurl.pl --keyname my-aws-account -- -X POST -H "Content-Type: text/xml; charset=UTF-8" --upload-file cf.xml https://cloudfront.amazonaws.com/2010-11-01/distribution

Point the cdn domain you entered in the cf.xml file to the domain returned in the block with a CNAME. You can also get this name from the AWS Management Console.

If you don’t already have WP Super Cache installed, install it now. Then go to Settings -> WP Super Cache -> CDN and enter the cdn domain name as the Off-site URL and check Enable CDN Support.

Clean out the existing cache and visit your front page, content like css, javascript and images should now be loaded from the CDN.

CloudFront with origin pull and WP Super Cache is a post from Fredrik Poller

The test was done using four servers (two on each site, one 256MB instance and one 512MB). All servers ran Ubuntu 10.10.

Without further ado, here’s the results (less is better).

There seems to be good capacity at both sites, performance was almost identical.

The following commands where used to do the benching, interesting values was the total time to run the test.

sysbench --num-threads=4 --test=cpu run
sysbench --num-threads=4 --test=memory run
sysbench --num-threads=4 --test=fileio --file-test-mode=rndrw prepare
sysbench --num-threads=4 --test=fileio --file-test-mode=rndrw run

Rackspace Cloud Servers, US vs UK is a post from Fredrik Poller