Posted in News on February 13th, 2010
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).
Paras Chopra
CEO and Founder of Wingify by the day, startups, marketing and analytics enthusiast by the afternoon, and a nihilist philosopher/writer by the evening!
I ♥ Split Testing Blog
Stay up to date
Follow on Twitter
Email Updates
Subscribe via RSSLatest Posts
Latest Tweets
- Interesting results from our new case study - "A/B Testing Between Free and Paid Signups: Sometimes Free is Better" http://t.co/gmd9jyBFwA #
- @JuliaFok Our $129/mo package that gives 30,000 visitors to test seems like a good fit for you. #
- New post on our blog: Extend Your Conversion Funnel Beyond the "Thank-You" Page http://t.co/rEEtlVrxv9 #
- RT @SantiagoEcomm: @Wingify's #SplitTesting blog is great resource to follow for knowledge & case studies on #ConversionRateOptimisation ht… #
- RT @chinchang457: The new toy @wingify >:) http://t.co/NbGLNZ0G61 #
Write for this blog!
We accept high quality articles related to A/B testing and online marketing. Send your proposals to contribute@wingify.com
15 Comments
February 13, 2010
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
February 13, 2010
@Stuart: Yes, latency could be an issue. In future, would need to use a CDN to host JS at multiple geographic locations.
February 13, 2010
Agree with first. Make a CloudFront folder on S3 and host your static content from there.
February 13, 2010
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.
February 13, 2010
@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.
February 13, 2010
@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.
February 14, 2010
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/
February 14, 2010
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.
February 15, 2010
@Andy: in fact, I am using your tool to manage S3. Loving it so far!
February 17, 2010
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. ;(
February 17, 2010
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.
February 20, 2010
We did some optimizations and the load time is around 230 ms now.. :)
April 28, 2010
[...] S3 hosting of JavaScript and now backend optimizations, the total response time has been brought under 350 ms. Aim is to [...]
August 5, 2010
[...] 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 [...]
August 5, 2010
[...] 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 [...]
Sorry, the comment form is closed at this time. To start a discussion, please email info@wingify.com.
RSS feed for comments on this post.