Content Delivery Networks – What, Why and WOW

Map of the world displaying network linksContent Delivery Networks, CDNs, origin push and origin pull…
Has your brain exploded yet? Don’t worry I know things might seem confusing now but let’s work on clearing some of that up. On my recent break from work I delved into the realm of CDNs and found out how impressive the results of using a CDN are in speeding up website page load times, as well as learning a lot of new things along the way which I will share today.

A bit about CDNs

First things first,  a CDN is a distributed network of servers that synchronise content between them. A content delivery network may have upwards of 15 geographical locations where they can serve content from. The important and distinctive feature of a CDN is that when a file is loaded by a customer the CDN will detect and send them to the closest server to get the content. The closer you are to the server the faster it loads. Therefore if two customers, one based in Sydney and one based in New York load the same file they will be sent to two geographically distinct servers greatly reducing the time required to load content.

With that in mind it is time to bust a little bit of jargon. An origin pull CDN defines a solution which does not require content to be loaded onto the CDN manually. By simply replacing the standard hostname with the CDN hostname, the CDN will either:
a) serve the file if it already has it, or
b) if it has never seen the file before (or it has expired) will load the file from you own server (the original hostname), cache it on the CDN servers for future hits and then serve it to the initial person loading it on the fly

The benefits of origin pull are that by simply changing the URL (either manually or programatically) you can easily enable the use of a CDN on a website or other web application for loading all the static content including files such as images, CSS and javascript files. If you have a look at this page you will see the Softlayer logo uses http://cdn[xx] rather than the standard link that WordPress would use ( and this is an example of how W3TotalCache has made it very simple to enable a CDN for this WordPress blog.

The alternative to an origin pull CDN is an origin push CDN which requires you to push/upload content to a storage area on the CDN and then link to the content. The difference between the two solutions is that origin pull is generally better for lots of small files such as Javascript, CSS files, XML and images that would be served as part of a standard blog. Conversely, origin push is required when you will be serving large files such as video, audio and streaming media. With this in mind, in an origin push setting you will also need to rent storage space from the CDN provider to store these larger files where as origin pull will generally only have a per Gigabyte charge.

Softlayer’s CDN

Softlayer LogoSo now with jargon aside, if you are in need of a CDN for your site I would strongly recommend Softlayer. In the coming weeks I will be putting a couple of posts together on issues I ran into, how to get things set up and most importantly how it all works.I can definitely say that once you work out the quirks it is extremely simple to get going (I know, I know… famous last words :D).

I would also like to give a big shoutout to the team at Softlayer for their assistance in helping me get my new CDN set up with them. Softlayer uses the Edgecast Content Delivery Network and has very reasonable prices ($0.12/GB USD), especially when you consider the worldwide coverage (which for me includes a POP here in Sydney).

The team has been extremely helpful in getting me up and running and I give them 12/10 for their support. The only thing I will say is, I feel the website wasn’t clear that the pay as you go option is exactly the same cost per gigabyte as the prepaid option (so keep this in mind, by going with pay as you go you only pay for what you use). Unfortunately once the CDN is set up as a prepaid you can not switch to pay as you go. I have learned this the hard way and have had to set up everything a second time. With that aside, page load times for my sites are through the floor and I am working on tweaking things further as I go. To provide some insight into just how much faster things are I I have reduced the page load time for the Technical Notebook homepage from between nine and ten seconds (outside of the US) down to around three to four seconds from most locations around the world.

For you bloggers out there if you use WordPress (self hosted) I would strongly recommend you consider looking at the possibility of a Content Delivery Network to help speed up your web site loading times around the world, also keep an eye out here on Technical Notebook in the near future for more info).

Hopefully this has been insightful and you might just have learned something new.


Proactive Information Exchange – A new term I have coined…

Communicate early and communicate often… In the current environment that we live in where we barely have time to stop and smell the roses this is an often forgotten vital point… Last night I was pondering this and came up with the concept of PIE, a.k.a. Proactive Information Exchange. It appears there are a few Google hits for it however I simply plucked it out of my brain last night and realised it is kind of a motto that I live by in my working life.

The concept of PIE or proactive information exchange is relatively simple. As I recently put it on a twitter status update:

... #PIE AKA #ProactiveInformationExchange to share knowledge to prevent #ShitHittingFans

So when you are working consider practicing the concept of PIE it really helps foster effective, and most importantly, early communication. Share your knowledge early in the hope that it can prevent someone running into issues you have faced in the past.

OOH and a massive thanks also go to @Rubenerd and his recent blog post for putting the word out.

/grabs a slice of PIE

Locked yourself out of Terminal Services? Give this a whirl!

One issue I have run into time and time again at work is when either myself or colleagues leave themselves logged into Terminal Services (using Remote Desktop Protocol or RDP for short) on a server and therefore lock out anyone but themselves from logging back ON to the server. Obviously this is targeted at servers running on the Wintel architecture.

This issue cropped up for me again and I was struggling to find a way to kick the other terminal services connections or terminate them or (well LOL I had a few other thoughts that were kinda graphic but hey we are trying to be professional here). Luckily a colleague was able to assist me and gave me this gem which I was unable to find elsewhere on the net (probably from a lack of the correct keywords).

If you need to force access to the console session for a host running Microsoft Windows Server 2003, MS Windows Server 2008 or probably a host of other Windows server and desktop hosts, give this little command line switch a try.

On the run command prompt of the computer you are connecting from (the guest) instead of running plain old ‘mstsc’ instead run ‘mstsc / -console /admin’.

I have no idea why (and will try to do some research later unless someone else can shed light on this) the straight up ‘-console’ switch did not work as a lot of people on the net said it would, without the ‘/admin’ switch I just kept getting the error “Terminal Services had reached the maximum number of licences” and so on.

So… I hope this helps you out next time pesky wabbits leave themselves logged onto your servers and stop you from logging on to RDP.