Update: for faster response time and better reliability, we have moved to Amazon CloudFront. This post is outdated, you should read this post instead.
During the last server outage, some of the websites where Visual Website Optimizer was running slowed down because our servers went down for a while. Even though we have upgraded the servers and installed server monitoring, possibility of the worst scenario concerns me a lot. Having one’s JavaScript code included in hundreds and thousands of websites is a HUGE responsibility. Slowing down of our servers means slowing down of customers’ websites. I perfectly realize that responsibility – that is why we chose to use extremely reliable Amazon S3 for hosting the JavaScript files. What this means for you is simple – in rare case of Visual Website Optimizer servers being down, your website will continue to function normally without any downtime. Additionally, hosting JavaScript files on Amazon will speed up the loading time because bandwidth is not a constraint with S3.
The JavaScript code snippet has been updated in all accounts of Visual Website Optimizer. It is highly recommended that you update the code included in your website with the new code to take advantage of this new feature. The new code is available in the test reports, ‘Add code to your website’ section.
For techies here is how we are using Amazon S3. VWO code consists of two parts: a) static JavaScript file; b) dynamic JavaScript file to determines which test is to be run on the current page and what variation to display. While we can host static JS file on S3, dynamic JS file needs to fetched from our servers. So, in presence of a dynamic file how do we ensure zero downtime? Well, the servers where dynamic JS file is hosted are monitored every single minute from two different locations. If monitoring script determines that the main servers are down, it uses S3 API to update the static JS file. The updated JS files signals the JavaScript code snippet that dynamic JS file isn’t available hence shouldn’t be loaded. Effectively this ensures minimal downtime even when external dynamic JS is included. Now, the only case when users’ website can slow down is when Amazon S3 itself goes down (which is unlikely since they are bound by SLAs).
RSS feed for comments on this post. TrackBack URL
Planning to push it out via Cloudfront? Latency & load times could be a worry for non-us sites. I’ve heard good things about hosting static JS on Akami (pretty sure that’s what ClickTale do).
Stu
Comment by Stuart — February 13, 2010 @ 12:37 pm
@Stuart: Yes, latency could be an issue. In future, would need to use a CDN to host JS at multiple geographic locations.
Comment by Paras Chopra — February 13, 2010 @ 12:41 pm
Agree with first. Make a CloudFront folder on S3 and host your static content from there.
Comment by Nicolai Kollner — February 13, 2010 @ 7:49 pm
We use the same architecture on UsabilityTest.com – where static JS file is hosted on Cloudfront and dynamic on our servers. It’s an important design decision we learned from our previous projects – as once you let users embed content from your own servers – it’s very difficult or impossible to make them change the code.
ALso, one important thing to note is to use custom DNS with Cloudfront or S3. so e.g. we have http://cdn.usabilitytest.com
We have made a mistake with previous project and our old URLs include Amazon S3 urls – this is not good as we cannot switch from Amazon S3 to another provider if there is a need in the future.
Comment by Janusz — February 13, 2010 @ 7:59 pm
@Janusz: you have a terrific point have. I have thinking of mapping cdn.visualwebsiteoptimzer.com to S3 but then decided it wouldn’t help a lot because DNS is hosted on the same network as our servers (Linode). So if Linode goes down, the DNS servers will go down as well.
Comment by Paras Chopra — February 13, 2010 @ 8:09 pm
@Paras – yeah. Good point. If you are using the same servers for DNS then there is a risk. We use GoDaddy DNS at the moment so it shouldn’t be a problem but thinking of migrating to Nettica or DNS Made Easy.
Comment by Janusz — February 13, 2010 @ 8:45 pm
I always enjoy learning what other people think about Amazon Web Services and how they use them. Check out my very own tool CloudBerry Explorer that helps manage S3 on Windows . It is a freeware. http://s3.cloudberrylab.com/
Comment by Andy — February 14, 2010 @ 5:32 pm
I always enjoy learning what other people think about Amazon Web Services and how they use them. Check out my very own tool CloudBerry Explorer that helps manage S3 on Windows . It is a freeware.
Comment by Andy — February 14, 2010 @ 5:32 pm
@Andy: in fact, I am using your tool to manage S3. Loving it so far!
Comment by Paras Chopra — February 15, 2010 @ 7:53 am
I still think the load time is to slow…here in Denmark i get takes around 900-1000ms to load the script from amazon. I would love to test it on a client but with these loadtimes i cant go ahead. ;(
Comment by Lars — February 17, 2010 @ 8:05 pm
Hey Lars, can you share screenshot with me? And if you really want it super quick, perhaps you’d like to host the JS locally on your host.
Comment by Paras Chopra — February 17, 2010 @ 8:42 pm
We did some optimizations and the load time is around 230 ms now..
Comment by Paras Chopra — February 20, 2010 @ 4:31 pm
[...] S3 hosting of JavaScript and now backend optimizations, the total response time has been brought under 350 ms. Aim is to [...]
Pingback by The challenge of realtime URL matching and how we do it « I love split testing – Visual Website Optimizer Blog — April 28, 2010 @ 7:52 pm
[...] the process is 28K (gzipped) JavaScript file download. The file was hosted on Amazon S3 (because of this) and we have now decided to switch to a CDN (Content Delivery Network) for serving the file. Our [...]
Pingback by Maximum theoretical downtime for a website: 30 minutes « I love split testing – Visual Website Optimizer Blog — August 5, 2010 @ 5:56 pm
[...] for serving static JavaScript file. Earlier we used Amazon S3 for this purpose (and the reason was this). But since now we have changed the failover mechanism, we can easily move to a CDN for delivering [...]
Pingback by Thanks to CloudFront, Visual Website Optimizer is faster than ever « I love split testing – Visual Website Optimizer Blog — August 5, 2010 @ 5:56 pm