WORK[etc] Web App Blog

We've been putting a whole lot of time and effort into making WORK[etc] fast.  Not that it isn't already fast, it's just that it needs to be faster. A whole lot faster.  For web and cloud apps to become fully mainstream, the user experience needs to approach the zippiness of using desktop apps.

Key to this is making sure infrastructure (ie the servers) are plugged into multiple internet backbones (ie massive data pipes) which we do already and that your WORK[etc] data flows as fast as it can down these pipes.  But problems arise when these pipes get jammed up because of events outside of our control.

The solution is to take WORK[etc] traffic outside of the public networks and piggy-back off uber-exclusive private network pipes.

Essentially this is what a C.D.N (Content Delivery Network) provides - a "private" network between the closest on-ramp to your laptop and WORK[etc] core infrastructure hub.  And in relation to web apps, it is all about network speed and priority access.

A simple way to think about this is to hark back to your nights of hanging out the front of nightclubs.  All the regular Schmoes (ie your data requests) have to queue for entry. 

Some Schmoes are lucky enough to go straight in.  Some Schmoes have to queue for varying lengths of time and the bigger the crowd, the longer the queue.  And then of course an unlucky few get totally rejected and have to either give up entirely or head to the back to the queue and start again.  It sucks being a Schmoe.

But if you've got your name on the door, aka VIP, aka private data network, then you're whisked straight in via your very own roped off, red-carpeted walkway.  No queuing, no rejection, no data-packet loss. 

A CDN, specifically optomized for web apps, is the red carpet to the cloud.

From the research I've done over the last 12 months, most startup web apps are not using CDN's to accelerate app performance over the cloud. 

Firstly, CDN's were originally designed for to host static content (ie pictures) on servers that were physically located closer to the end user and as such the performance gains just were not evident when delivering dynamic content such as that from a web app.  And secondly, CDNs' have traditionally been crazy expensive to roll out.

But this is changing.  All the major providers are refining their technology to speed up network delivery of dynamic content. 

WORK[etc] customers already know we've been extensively testing a number of providers and have recently selected the Akamai Web Application Accelerator product. 

This is why:

Test Results - ~100% Speed Improvement

Our test scenario took a single WORK[etc] customer database, made it available via the accelerated and standard web addresses and then used a robot to perform a number of common tasks (ie log in, look up a contact, perform a search, review a project, log out).  We then recorded the length of time it took to perform the task list when using the Akamai-enhanced network versus the standard public network.

Below are the results of running the test every 20minutes, charted over a 24hr period last week.