Static content delivery on “edge servers” is something that Akamai, LimeLight, Highwinds, Panther Express, and the like have been selling as the core of their content delivery network (CDN) services.  If you read my last post then you’re already familiar with the concept of the “edge” and the “origin.”  For those who didn’t, the “edge” is basically where end users access a SaaS-type web application and the “origin” is where the content you want to accelerate lives.

Typically, end users, who are considered as being part of the “last mile,” experience greater latency and/or packet loss (resulting in poor end user experience) by going beyond the “edge.”  Without an edge delivery service, end users have to go from the “last mile,” to the “edge,” to the “middle mile (depending on who you ask and where the end user is),” to the “backbone.” 

Note:  Anyone concerned with end user performance should get transit from a major backbone provider in order to deliver the fastest possible to the most networks.  Static edge delivery will still shave time off of the overall transaction but the performance benefit is greatest when the origin is on a major backbone, or someone like InterNAP.

Most of the above-mentioned services work by having a number of servers strategically located in the major edge networks which cache the static content going out to the end users.  If a file is being requested for the first time (from the perspective of the edge server), a request is made back to origin for the file and then transparently sent to the end user.  From that point on, the accessed edge server will cache a copy of whatever files were requested for a configurable period of time (cache TTL).

In order to not impact end user experience when requesting a file that the edge doesn’t have, the origin request is accelerated through what is usually a proprietary network acceleration algorithm.  In a nutshell, the CDN companies rely on an algorithm faster than BGP in order to appear seamless.  Akamai, for example, utilizes their SureRoute platform as the cornerstone of most of their acceleration services.

A typical end user transaction for static content delivered by edge servers looks like the following:

- user requests some URL which is accelerated at the edge
- the user is directed to the fastest local edge server, as determined by the CDN provider, either via BGP Anycast or DNS redirection
- if the edge server in question doesn’t have the requested content, the edge server makes a request to origin on an accelerated and/or optimized path
- once the edge server has the data requested, it is cached per policy and served to the end user

It’s worth mentioning before we get any further that hostnames and URLs are what is accelerated, not networks, servers, or anything along those lines.

If we assume the user to be in New York and the origin to be in San Francisco, we are able to shave a lot of time off in the transaction.  A request spanning the width of this country, on average, takes something on the order of 200ms.  That’s 100ms spent going from NY to SF and another 100ms spent from SF to NY.  While 200ms isn’t a big deal for most people, keep in mind this is 200ms for each and every request on the page.  So if you host a website with 50 10k images, end users in NY will have to wait a theoretical maximum of 10 seconds just for network latency.  (Since we’re assuming static content here origin server performance is rarely an issue.)  For comparison, routing to the edge of Comcast’s residential cable network in SF takes something like 15ms.  For the example above, the same 50 objects will take less than a second (~750ms) to download in an edge delivery scenario.  There is a slightly longer latency for files being requested for the first time but that should only affect one user once, with all subsequent requests happening at accelerated rates.

Please do not consider the CDN references above to be an endorsement of any type.  I am only trying to relay information, it is up to you to find the best network to suit your needs.

I live in a world of end user experience management.  The SLA’s I have in place with my customers are quantified in milliseconds, and as such we employ a strategy known as edge acceleration.  Edge acceleration can mean different things to different people, but those who have a SaaS (Software as a Service) model treat the “edge” as the network physically closest to the end user and the “origin” is where the application(s) is hosted.

For web-based applications, the following almost always happens (regardless of industry, form, or function):

Steps (necessarily very high-level)
1) user pulls up some hostname (app.company.com) in a browser
2) user sees a page, usually a login page, accompanied with text and images
3) user logs in and proceeds to use the application in any number of ways

Since these three steps are effectively universal in SaaS, it is worth our while to analyze these steps in an effort to increase the accessibility of these things from the edge.

Analysis
1) An end user typing a hostname into the address bar of his browser and clicking “go” triggers a number of events.  First, the hostname typed in needs to be resolved to an IP address via DNS.  Once the IP is known, our end user connects to the IP requested, and issues HTTP GET’s based on the server response (HTML).

Leveraging an edge DNS service, such as Akamai’s eDNS service, will ensure that a nameserver most accessible to the end user will pick up the request and respond.  This is theoretically faster than having ns1.company.com hosted in Silicon Valley with end users in New York.  With eDNS, users in New York will have their requests answered by servers which are usually physically much closer, and therefore faster.

2) An end user downloading and rendering the login page of a web-based application is probably the easiest part to deal with.  Since there’s nothing user-specific at this point generally object here are statically cacheable.

Leveraging an edge HTTP content delivery service, such as Akamai’s EdgeSuite service, tries to make sure the end user will be downloading this static content from a webserver cache somewhere closer than the origin.  Static content here typically includes JavaScript, JPG, GIF, PNG, CSS, and text.  Edge delivery services also tend to add gzip compression to these files, reducing data transfer and speed to transfer.  Files are cached for some configurable time and new files are retrieved from origin by the edge servers when an end user makes a request.

This is a well-understood problem and solution, and most CDN’s in existence today basically provide this as a baseline service.

3)  Once a user types in their identifying information and clicks login is where the complexity gets introduced.  Usually when a user clicks the login button, there’s a database lookup to validate user-supplied credentials, a session is instantiated for the user, amongst other things.  In either case, these server-side events require end user interaction with the origin and the edge delivery model above simply cannot handle it.  For this, a new trend in CDN technology has developed in the form of dynamic application acceleration.  Akamai’s service in this arena is called Web Application Accelerator (WAA) and utilizes their SureRoute technology to pass end user traffic back to origin and vice versa.  In theory, WAA bypasses the BGP that most providers use by maintaining their own (more optimized) route tables, thereby decreasing the latency an end user experiences.

Since this is a relatively new challenge to address en masse, it’s understandable that Akamai’s solution leaves a lot to be desired.  However, their service is significantly faster for almost any type of application, and smaller companies simply don’t have the expertise or funds to build their own application acceleration infrastructure.  The major online retailers and MMOG operators figured this out years ago and have been building out their own infrastructure, but the cost-prohibitive nature of these undertakings is a large obstacle to overcome.

Interesting note:  there have been more and more companies competing in the application acceleration space with packaged solutions but I think we’re still a bit aways from having your average medium-sized SaaS company deploy these things.