This Howto will explain how to use CirruxCache to serve the static content of your WP blog from Google with the help of OSSDL CDN off-linker.

Part 1: create a Google App Engine account

First, you have to own a standard Google account. If you got Gmail, you got a Google account :). If you still don’t have such, I think it’s time you step out of your home :).

Note for Google App users: your custom domain account works too!

Head now to https://appengine.google.com or https://appengine.google.com/a/your-domain.tld depending of your type of account and sign in with your account. Of course, you read the whole licence agreement and noticed that you free Google App Engine has a limited quota of bandwidth (fair enough) but also CPU usage (?), requests limits (??), storage cache (wait?!), etc. This is the how cloud computing works and you should look at this page about quotas. You will start with a free account and if you need more, you can apply for a billed account.

Now, create your first Google App Engine application. You will have to name your application by providing a title and an app name.  This latter will be used as the subdomain of your application (« mycdn.appspot.com »). Remember the app name because your will need it later.

Part 2: configure and deploy CirruxCache to Google App Engine servers’

Before configuring CirruxCache and to be able to deploy it, you will need to install Google App Engine SDK. This step is necessary because Google only allows upload of applications from theirs tools.

At first, you need to install Python 2.5.x from Python website. It’s one of the programming language used by Google to power up the service. The current version compatible with the App SDK is 2.5.4.

After completing Python installation (should be easy enough, it’s a matter of « Next, Yes, Next »), download the Google App Engine SDK from Google website. Install it with the default package and options.

Retrieve CirruxCache from the project website and download the latest package containing the source files. Untar the archive somewhere on you computer and launch your favorite text editor on app.yaml. You should found a line starting with application: appname. Replace appname by the name you choose when you created the application. The line should now look like this : application: mycdn.

Now the tricky part, you have to tell CirruxCache where it can fetch the static content. CirruxCache works by pulling the file from the original website. This is called « Origin Pull » and this method saves a lot of hassle. When configured, you have nothing to do when you add more static content to your website. Everything is cached automatically.

Open app.py with your text editor and look at the URL mapping section. You have some URLS already preconfigured but for our purpose, we will not use then. Assuming, your blog resides at http://mydomain.tld/blog, you have to configure this section like this:

urls = (
'(/blog/.*)', 'Blog',
'/_cron/(.*)', 'Cron',
'(/.*)', 'Root'
)

and add the following Point Of Presence:

class Blog(Service):
origin = 'http://www.mydomain.tld'
forceTTL = 2592000
ignoreQueryString = False
forwardPost = False

By setting this, you tell CirruxCache to handler every incoming request from the base URL http://mycdn.appspot.com/blog and to fetch all the necessary data from http://www.mydomain.tld/blog.

That’s right, each time, you request http://mycdn.appspot.com/blog/wp-content/myphoto.jpeg, it will take a look at its own cache and if not available,  it will fetch from http://www.mydomain.tld/blog/wp-content/myphoto.jpeg and store it for the next similar request.

Of course, you can fine-tuned these URLs to fit your needs. This generic configuration could cache everything from your blog.

As for the others settings, you can take a look at this page.

We will now test the configuration by launching a local App Engine instance on your computer. To do so, fire up a Terminal/Command line window and change directory to the location where you unarchived CirruxCache, then type dev_appserver.py . (notice the second dot). It will launch a web server with CirruxCache on it. Start your web browser and go to http://localhost:8080. Take the URL of a picture from your blog and append it to the URL (remove the domain). You should obtain something similar to this: http://localhost:8080/blog/wp-content/myphoto.jpeg. If you can see your picture, that means it works!

Deploy the application to your Google App Engine account by opening a new command line window (and CD to the CirruxCache directory) and type the following command: appcfg update . (notice again the dot). It will ask for your account credentials. In a minute, you CDN should be live at the chosen URL.

Part 3: configure Wordpress to use CirruxCache with OSSDL CDN off-linker extension

This is cool but how can I tell Wordpress to use my brand new CDN for my static content? Here comes OSSDL CDN off-linker extension for WP available here. It will rewrite every links of your blog which point to wp-content or wp-includes with an URL of your choice. This extension comes handy as it does what we want.

Install it just like any WP extension and head up to the configuration page (WP Admin > Settings > OSSDL CDN off-linker). Put your Google App Engine URL followed by the mount point: http://myapp.appspot.com/blog

Part 4: profit!

Refresh any cache you have (WP Cache, WP Super Cache, etc.) and the URL of your static content should now be rewritten to your CDN!

Enjoy.

• CirruxCache
• OSSDL CDN off-linker
• Google App Engine

Les RPS de OVH sont des serveurs dédiés qui ont la particularité d’avoir des disques déportés sur un SAN (un maxi serveur de stockage). Puisque vous partagez une ressource mutualisée (le disque et seulement lui), des limitations et qualité de service ont été mises en place. De ce fait, une trop forte activité disque pendant une trop longue période vous catégorise en « mauvais utilisateur » et place vos I/O disques en basse priorité. En conséquence, vous avez des accès disques exécrables… Pas d’avertissement, pas d’email, vous n’êtes pas prévenu [1].

J’ai eu cette surprise cette semaine avec le serveur RPS qui héberge le domaine a-l.fr. C’est après une longue discussion sur la mailling list OVH que le grand manitou (comme on l’appelle) a bien voulu rebasculer mes I/O disques en priorité normale… Ensuite, pourquoi j’ai été catégorisé abuseur d’I/O, je n’ai pas eu de réponse détaillée. Je soupçonne fortement le crash disque du SAN de mon RPS suivi de son reboot et du lancement des nombreux services (web, ftp, mail, jeux) d’être la cause.

Mise à jour du 12/06/09 : OVH a clarifié certaines choses en instaurant des paliers de performance atteignables sur les RPS. En gros, 3 offres IO proposées : Standard, Premium, Business. Voir le site de OVH pour plus de détails.

Mise à jour du 21/08/09 : la gamme RPS s’arrête le 15 septembre. Les commandes ne seront plus possibles (plus de migration) mais vous pourrez garder votre RPS, toujours au même prix.

Mise à jour du 29/11/09 : la gamme RPS existe toujours. OVH semble avoir fait machine arrière. Cependant, pas d’annonce officielle …

[1] il semble que des graphes des I/O vont bientôt être mis dans le Manager OVH.

Màj : firmware retiré. Il souffre du même bug qu’auparavant… En gros, le réseau n’a plus d’accès à l’extérieur (Internet) pendant une trentaine de secondes lorsqu’un nouveau élément entre dans le réseau (connexion d’un cable éthernet, connexion wifi d’un ordinateur, …).

Pour les amateurs de jeux dangereux, voici les firmware recompilés qui font tout tout seul. Flasher et admirer l’autoconfiguration IPv6 de vos machines. Utilisation à vos risques et périls évidemment. Mon routeur étant un Linksys WRT54GSv4, il est quasi sûr que vous ne risquez rien si vous flasher l’image pour le GSv4. Par contre, le build a généré d’autres images correspondant à d’autres modèles que je n’ai PAS testé. Je les laisse dans l’archive mais soyez très prudent. Préparez-vous à faire du TFTP ou du JTAG (et si vous ne comprenez pas, ce n’est définitivement pas pour vous !).

• DD-WRT v24 SP1 avec support de l’IPv6 du FAI Free