A CDN and Cookie-Free Domains

I’m doing this a bit out-of-order compared with how I actually configured my server, this I’m presenting this in a way that will require the least amount of backtracking. If setting up a CDN seems like too much work, you can skip this one and wait for the next part (GZipping).

One of the things YSlow gave me an “E” on (wow, worse than an F) was cookie-free domains. I’m using Google Analytics to track visitors on my site, and the way it accomplishes this is with cookies.

Cookies are a perfectly valid thing these days, however setting a cookie for my domain, vcsjones.com, meant that all static content like CSS, JavaScript, and images were sent with the cookie. Analytics was setting cookies when someone hit my site, and the web server was happy enough to send along the cookie header with this static content.

The typical solution for this is to use a cookie free domain, i.e. use a different domain for your static content. I couldn’t use a subdomain like static.vcsjones.com because cookies set at vcsjones.com also apply to all child domains. My only option to using a cookie free domain was to purchase another domain and serve static content from there, like staticvcsjones.com.

However, before I did any of that, YSlow suggested I use a Content Delivery Network, or CDN, for my static content. If I moved my static content to a CDN, then I would be taking care of the cookie free domains problem as well.

On the theme of using Amazon for everything, I settled on giving CloudFront a shot. CloudFront is Amazon’s content delivery network solution.

I had a couple of choices on how I wanted to set this up.

Host my static content elsewhere (bad)

I had originally gone the route of trying to move all of my static content to Amazon’s S3 solution. CloudFront is easy to configure to serve content from an S3 bucket, but this turned out to be a troublesome approach from a maintenance standpoint. I would not only need to move all of my uploads to S3, but also the theme content, and other “innards” of WordPress. This would be difficult keeping things up-to-sync. I wasn’t able to find a WordPress plugin that could keep all of that in sync for me, and manually uploaded content to S3 seemed tiresome. It would also mean any time I upgraded a plugin, theme, or WordPress itself, I would need to move all of those files to S3 again. This didn’t seem like a workable approach.

Leave my static content as is (good)

I could leave my static content exactly where it is, and set up CloudFront to use my own server as a source of static content. This seemed like the best approach. If my file content changed, the CDN would pick it up (eventually). Any new files would instantly be picked up by CloudFront, and I wouldn’t have to change where WordPress’s physical files were. That would better for upgrading and plugin changes.

Making it all work

I had initially set up CloudFront to point to vcsjones.com. That worked well enough, CloudFront served anything from my server in its edge cache. This however, left me with a bit of a yucky feeling: any dynamic content could possibly end up in CloudFront’s cache. I wasn’t a big fan of that, so I decided to truly separate my static content from my dynamic content, even if they were all in the same place.

I first brought up a new subdomain, static.vcsjones.com. I had it pointed to the same physical location as vcsjones.com. At first, this was a true 100% copy of vcsjones.com. My next intention was to configure nginx, my server, to only serve static content from static.vcsjones.com, and block it from vcsjones.com. As a last step, I would configure CloudFront to use static.vcsjones.com as an origin.

Configuring NGINX

NGINX is a great server, and I love its flexibility and speed. My static content virtual site configuration looked like this:

server {
    listen          80;
    server_name     static.vcsjones.com;
    root            /var/www/wordpress/;

    location ~* \.(?:js|css|png|jpg|jpeg|gif|ico)$ {
        expires max;
        add_header Pragma public;
        access_log off;
        break;
    }

    location / {
        return 404;
    }
}

This is an abbreviated version of what I currently have running now. So static.vcsjones.com will only serve static content, which helps mitigate the possibility of an search engine finding this domain somehow and dinging my SEO rankings for serving duplicate content.

So, vcsjones.com is being used to serve dynamic content, static.vcsjones.com is used to serve only static content, and my CloudFront CDN is using static.vcsjones.com.

Finally, I blocked static content from vcsjones.com with a few exceptions.

location ~* \.(?:js|css|png|jpg|jpeg|gif|ico)$ {
    if ($http_referer ~ "wp-admin") {
        break;
    }
    if ($request_filename ~* jquery\.js$) {
        break;
    } 
    return 404;
}

This blocks static content from vcsjones.com unless it is jquery, or if the referer contains wp-admin.

jQuery is a bit of a special beast in WordPress. It doesn’t appear to be easy to cache via a CDN because WordPress dynamically builds it depending on what the extensions ask for.

wp-admin is whitelisted as a referer because we don’t want to break the admin section of WordPress, which appears to be a little more difficult to fix URLs in.

Fixing URLs in WordPress

So now with this fancy-pants CDN, I actually needed to use it. For now, I am using two WordPress plugins to accomplish this.

CDN Rewrite works well to rewrite content from WordPress’s themes and includes. This changes my theme to load its CSS, images, and JS from CloudFront. The exception to this is jQuery. jQuery in WordPress is an odd beast, it appears that WordPress dynamically builds jQuery depending on what pieces of it is needed. For that purpose, jQuery is not served over my CDN to my site, which is rather unfortunate (though it is gzipped).

Real Time Find and Replace works well to rewrite content in actual post bodies, that CDN Rewrite doesn’t seem to do.

My intention is to eventually eliminate both by fixing the actual links in post bodies, and creating a child theme. This will be a small improvement such that WordPress has less processing to do on the rendered HTML.

Due to the odd handling of jQuery in WordPress, neither of them catch the URL for jQuery, so jQuery is served outside the CDN, which is actually rather unfortunate.

CloudFront CNAME

One option CloudFront has is the ability to specify a CNAME in your DNS to CloudFront. I initially took this approach because it allowed more control over where my static content was located. If I use my CDN endpoint, dsdujlkb89x0f.cloudfront.net, that would mean if I spent all that time fixing static content URLs, I would have to fix them again if I opted to not use CloudFront. Initially I had setup cdn.vcsjones.com to point to CloudFront, but because it is a subdomain of vcsjones.com, it was getting Google Analytics cookies. Instead I opted to just use CloudFront’s domain. This keeps my static content cookie free, and also means I won’t pay for DNS lookups in Route 53.

Gotchas

This CDN approach works well for me, with a few issues that are acceptable trade offs, or is easy to work around.

Because I disabled static content on vcsjones.com to better separate the static content, the Administration bar is a little broken when used outside of wp-admin.

CloudFront has no easy to purge all of its cache. If you need purge something from CloudFront, you need to specify the path you want to purge, including the query string.

More of this series

1. Scaling WordPress Part 1: DNS
2. Scaling WordPress Part 2: CDN

As I was looking at my server’s details and utilization, I came to the realization that whatever reason my site was slow, it was not because the server was overworked. In fact, it was sitting there idling most of the time.

When I gave it some thought, I realized that while my website was working just fine, I had never spent any amount of time tweaking the server for performance. I decided to see if tweaking some caching settings would improve things a bit.

And man, did they improve. I started by using a browser extension called YSlow to determine where I needed to focus my improvements, and start with some low-hanging fruit. Initially, YSlow gave my site a big orange D as a grade. I decided over the weekend to see how high I could improve things. My journey required tweaking of WordPress, DNS, and getting a CDN involved.

DNS Matters

The first thing that got pointed out to me was that my DNS was slow. Several hundred milliseconds to resolve my site. I never really gave DNS performance that much thought. I had just went with the free DNS that my domain registrar provided. While free, I got what I paid for.

Almost all of my infrastructure is on Amazon AWS, so I looked at Route 53 to transfer my DNS to. This would increase my costs slightly, but it boiled down to hardly a dollar extra a month. The zone costs $0.50 per month, plus another $0.50 per million queries. This won’t break the bank, if my site ever gets that popular, I have bigger problems I need to worry about. Additionally, later on, we’ll be offloading a lot of DNS queries to a CDN.

One thing with Route 53 that you may want to tweak is the default TTL (Time-To-Live). It defaults to 300 seconds, which is rather low considering my DNS settings don’t change that much. Rather I set it to 2 hours (7200 seconds) so the DNS would be cached longer, thus reducing the number of lookups. I’d be surprised if I paid more than $0.50 a month for DNS queries.

This had a moderate, measurably small improvement on the performance of my site, but only the first time you hit it if the DNS isn’t cached. I still had a ways to go, but it was a step in the right direction.

Next time, we’ll look at setting up a CDN (Content Delivery Network) for serving static content.

More of this series

1. Scaling WordPress Part 1: DNS
2. Scaling WordPress Part 2: CDN

This proved to be a little challenging to me, as I didn’t want to resort to using a 3rd party solution in .NET like BouncyCastle or a managed OpenSSL wrapper. Turns out, it’s not that hard, if just a little under-documented. Starting with Objective-C, here’s how I am generating an RSA key pair.

Assuming you have an RSA* object from OpenSSL, you can export the public key like so:

-(NSData*)publicKey {
    int size = i2d_RSAPublicKey(_rsa, NULL);
    unsigned char* temp = OPENSSL_malloc(size);
    //the use of a temporary variable is mandatory!
    unsigned char* copy = temp;
    int keySize = i2d_RSAPublicKey(_rsa, &copy);
    NSData* data = nil;
    if (keySize > 0) {
        data = [[NSData alloc] initWithBytes:temp length:keySize];
    }
    OPENSSL_free(temp);
    return data;
}

For illustrative purposes: Don’t forget to do error checking!

So now we have an NSData, but how is this public key actually stored? How can I use this in .NET?

The first thing to understand is the format by what format i2d_RSAPublicKey exports data. This exports the data in ASN.1 DER format, and getting that into an RSACryptoServiceProvider is possible with no 3rd party support.

private static readonly byte[] _nullAsnBytes = new byte[] {0, 5};

public RSACryptoServiceProvider GetCryptoServiceProvider(byte[] asnDerPublicKey)
{
    const string RSA_OID = "1.2.840.113549.1.1.1";
    var oid = new Oid(RSA_OID);
    var asnPublicKey = new AsnEncodedData(oid, asnDerPublicKey);
    var nullAsnValue = new AsnEncodedData(_nullAsnBytes);
    var publicKey = new PublicKey(oid, nullAsnValue, asnPublicKey);
    return publicKey.Key as RSACryptoServiceProvider;
}

The 1.2.840.113549.1.1.1 value is the OID for RSA, or the actual header name szOID_RSA_RSA. We use a ASN.1 value of null ({0, 5}) for the parameters, and then we pass the AsnEncodedData to the PublicKey class, from which we can obtain an RSACryptoServiceProvider from the public key.

Together, these two code snippets allow working with RSA public keys in Objective-C (iOS or Mac) and in .NET.

*What is it?* You might ask? MADExpo is a conference in Virginia Beach (yes, by the beach!), Virginia focusing on a wide variety of software and hardware, such as Ruby, .NET, Gadgeteer, or whatever might be trending. It provides a great chance to learn about new things, and interact with people in a friendly environment.

Registration is open, and the speaker lineup is sure worth looking at.

And not to mention, MADExpo is kid-friendly with the MADKidz mini-conference where kids get a chance to tinker with coding, robotics, and electronics.

I’ll be there talking about CoffeeScript and TypeScript, two of my favorite things to work with these days.

If you have the opportunity to come to MADExpo, don’t miss it!

Mac usersneed to test your sites under IE10 and IE8? Donate to charity and MS will send you Parallels and VMs bit.ly/11h6lrV

— Barry Dorrans (@blowdart) April 2, 2013

All you have to do is donate $25 to a charity of your choosing and they’ll ship you a USB key. Frankly this is a hard deal to pass up, and I really applaud Microsoft’s support of charities. Parallels itself retails for more than $25, so to get a copy of that plus Windows for testing your site in Internet Explorer is nothing short of awesome.

You can learn more from the IE team’s blog post.

The driver updates fix a few little issues, like the volume indicator not appearing on screen when using the function keys for volume.

The first thing I did was check for driver updates with the Apple Software Update utility, where I did not get any luck. I’d check there first incase they add them later. If they aren’t there, you can update them by downloading them here from Apple’s Support Downloads. Download the latest Boot Camp drivers, unzip them, and run setup.exe in the “BootCamp” directory, and the Boot Camp software will update the drivers that are already installed.

https://github.com/vcsjones/Presentations/tree/master/RockNUG.2013.03

PowerPoint and Keynote slides are available, as well as the sample code we worked through.

All code and slides are Creative Commons Attribution 3.0 Unported License.

The one that stands out the most is CoffeeScript’s new Literate Programming feature. The literate programming feature introduces a new file extension for CoffeeScript, “.litcoffee”, that behaves the same as regular CoffeeScript, with one detail: unless the code is indented, it is ignored. This allows you to put documentation in your CoffeeScript without obtrusive comment regions, and probably without coincidence, plays well with the Markdown syntax as well since code in markdown is indented. An example .litcoffee file:

This is documentation about a class called **Foo**.
The Foo class does many things, such as supply bars.
If the Foo class runs out of bars, it returns
**Baz** objects until there are more bars.

    class Foo
        constructor:() ->
            @foo = 'bar'

When compiled, it results in the following JavaScript:

var Foo;
Foo = (function() {
  function Foo() {
    this.foo = 'bar';
  }
  return Foo;
})();

The original documentation text is no where to be found. However when run through a Markdown parser, the result is this:

<p>This is documentation about a class called <strong>Foo</strong>.
The Foo class does many things, such as supply bars.
If the Foo class runs out of bars, it returns
<strong>Baz</strong> objects until there are more bars.</p>

<pre><code>class Foo
    constructor:() ->
        @foo = 'bar'
</code></pre>

This makes it very easy to treat your CoffeeScript files as both a markdown file and a CoffeeScript file. This is a nice feature, though I can’t honestly say I find myself making excessive use of the feature.

$.ajax({
 //URL and settings
}).done(() => {
	alert('all done!');
});

This compiles to this JavaScript:

$.ajax({
 //URL and settings
}).done(function () {
    alert('all done!');
});

Which really isn’t all that surprising. TypeScript borrowed that arrow function syntax from ECMAScript 6′s current draft. Buried deep in ES 6′s definition, it talks about how “this” is bound to the “this” of the outer function. Douglas Crockford has a great write up covering all of that.

TypeScript follows ECMAs rule and binds the “this” to the outer this. Notice how this TypeScript compiles:

$.ajax({
 //URL and settings
}).done(() => {
	alert(this);
});

var _this = this;
$.ajax({
 //URL and settings
}).done(function () {
    alert(_this);
});

The resulting JavaScript captures the value of “this” and uses the “this” outside the function. Now, if you you’ve CoffeeScript at all, this probably feels right at home to you, but I have concerns about this in TypeScript, and to an extent ES 6 too.

My concern around this stems from that many JavaScript frameworks make good use of “this” in their callback functions. jQuery is a prime example of this. The settings object of the $.ajax function takes a context value:

This object will be made the context of all Ajax-related callbacks. By default, the context is an object that represents the ajax settings used in the call ($.ajaxSettings merged with the settings passed to $.ajax)

This no longer works if I were to use arrow functions as part of my jQuery done callback:

$.ajax({
	url: "http://example.com",
	context: "astring"
}).done(() => {
	alert(this);
});

One would expect that to alert “astring”, but of course it won’t because the meaning of “this” is no longer what we expect. The only way to work around this behavior in TypeScript at the moment is to fall back to a plain function:

$.ajax({
	url: "http://example.com",
	context: "astring"
}).done(function() {
	alert(this);
});

So be careful when you start using TypeScript’s arrow functions. You can’t just go around replacing functions with arrow functions, unless you want “this” to break.

My concern around arrow functions is many people won’t understand that it isn’t just syntactic sugar – it’s a change in behavior and many will gloss over that fact at first. Arrow functions have a cleaner syntax to me, but I can’t use them everywhere because of that change.

TypeScript has a unique advantage where it doesn’t have to completely align itself with ES. ES 6 makes absolutely no mention of types variables or parameters, or interfaces. I would propose that TypeScript adopt “skinny arrows”, similar to CoffeeScript. For example:

$.ajax({
	url: "http://example.com",
	context: "astring"
}).done(() -> {
	alert(this);
});

Now our callback works as expected.

This is well known in the CoffeeScript community. Skinny arrows don’t capture this, while fat arrows do (though in CoffeeScript you would use “@” instead of “this”).

Now I can have that cleaner syntax while having the flexibility to control how “this” behaves.