Speeding Up Your Site with Regional Data Collection

Analytics · By On · 4 Comments

Let’s face it; your site is never fast enough. That’s why you use pre­cious devel­op­ment time to:

  • Lower page weight
  • Cache more of the page
  • Opti­mize JavaScript
  • Use con­tent deliv­ery net­works (CDNs) to push con­tent closer to the visitor

For this rea­son, there’s one part of your site that we’ve been work­ing to speed up: the ana­lyt­ics. For instance, ear­lier this year we release ver­sion H.20 of our JavaScript code. It’s the fastest yet-taking advan­tage of native browser func­tion­al­ity to avoid any notice­able JavaScript delays. More recently we’ve built a regional data col­lec­tion net­work, push­ing our con­tent (the 1×1 pixel image) closer to your site vis­i­tors. This sec­ond enhance­ment is excit­ing because it’s built on a very robust, very smart archi­tec­ture; and because it’s light­ning fast.

As of today, five data col­lec­tion cen­ters have been setup around the globe, each respond­ing to mil­lions of requests in less than half the time of the stan­dard net­work. Those col­lec­tion cen­ters are in Lon­don, Tokyo and the US, with more being con­sid­ered globally.

What Does this Mean For You?

In short, this means that your site will be faster for vis­i­tors around the globe. If you’re curi­ous, here’s a descrip­tion of some details. If not, just skip to the “Results” section.

Your data is processed in one of two US-based data cen­ters. Cur­rently, vis­i­tors to your site request lit­tle images from that data cen­ter, regard­less of where they are in the world. Long dis­tances, espe­cially across oceans, can result in poor response times for those images.

Regional data col­lec­tion lets site vis­i­tors request data from the data cen­ter near­est them, not nec­es­sar­ily the data cen­ter where your data is processed. Those data col­lec­tion cen­ters respond imme­di­ately with an image, and then for­ward the data on to the data cen­ter for processing.

This works just like a CDN-pushing con­tent closer to the vis­i­tor for faster response times.

The Results


On aver­age, the new sys­tem responds in half the time of the old sys­tem. Response time for vis­i­tors in North Amer­ica improves by 38%, while response time for Euro­pean vis­i­tors drops by a whop­ping 83%! Here’s some more detail:

How to Get On the New Network

This is when peo­ple typ­i­cally ask: is there any rea­son not to use regional data col­lec­tion? The answer: no. Come over as soon as you can. We’re mov­ing cus­tomers over as quickly as our capac­ity allows, so it’s a first-come first-served pri­or­ity. Here’s the gen­eral process:

  1. You tell your account man­ager you’d like to migrate
  2. Omni­ture gets ready by deploy­ing your SSL certs and/or giv­ing you col­lec­tion domain info
  3. After your go-live date, you make the switch by either
    a. Updat­ing your DNS CNAME record (first party cook­ies only), or
    b. Updat­ing your JavaScript file(s)

More details are avail­able in the white paper RDC (Regional Data Col­lec­tion) Tran­si­tion, avail­able in the Knowl­edge Base (arti­cle 9937).

Typ­i­cal Follow-On Questions

Once we start talk­ing about regional data col­lec­tion, a num­ber of ques­tions come up. I’ve addressed many of them here. Your AM should be able to answer any others.

Will data take longer to show up in reports?

No; at least not that you’ll be able to notice. Col­lec­tion cen­ters for­ward data to pro­cess­ing cen­ters in sec­onds. Since traf­fic data is typ­i­cally avail­able in 30–120 sec­onds, you prob­a­bly won’t notice the change.

Is this sys­tem as robust as the cur­rent system?

Yes, in fact it’s more robust. Not only does each col­lec­tion cen­ter have redun­dancy built through­out, the net­work of col­lec­tion cen­ters pro­vides another layer of redun­dancy. If a col­lec­tion cen­ter is unable to reach the desired pro­cess­ing cen­ter, it for­wards the data to a col­lec­tion cen­ter that can send the data to a pro­cess­ing cen­ter. Addi­tion­ally, if one col­lec­tion cen­ter goes com­pletely down for any rea­son, we have mul­ti­ple back-up col­lec­tion cen­ters ready to step in.

What about regional pro­cess­ing centers?

Cus­tomers out­side of the US typ­i­cally won­der whether they can get faster report speed by hav­ing a data pro­cess­ing cen­ter in their region. While we are con­sid­er­ing build­ing those out, we’re cur­rently focused on other ways to speed up report­ing around the globe.

Where will the next regional col­lec­tion cen­ters go?

We’re con­sid­er­ing many loca­tions for 2010, but we’re not ready to talk about any yet. We’re going to focus on areas where you have or will have the most vis­i­tors, so let me know if you’ve got plans to expand to new regions. Your AM will be able to con­nect us if you’d like to talk to me directly.

Sum­mary

Regional Data Col­lec­tion is live and in use by high-volume sites. I’ve helped mul­ti­ple cus­tomers through the migra­tion process, and it’s sur­pris­ingly sim­ple to move over. Call your account man­ager to get started, or down­load the whitepa­per if you want some more details.

  • http://insightr.com James Dut­ton

    Bret,

    Inter­est­ing arti­cle, though based on what I’ve read here I assume this is a process rec­om­mended for all Omni­ture cus­tomers — I can’t see any rea­sons why an organ­i­sa­tion might be con­cerned about the migra­tion (beyond the *poten­tially* com­plex issues of js file migra­tion). As such would it not be appro­pri­ate for Omni­ture account man­agers to share this with their cus­tomers as a mat­ter of cour­tesy to say ‘hey there, we’re now con­sid­er­ably faster.. would you con­sider these steps?’.

    I’d be curi­ous if you could share just how bad the US cen­tric sys­tem was before / after — par­tic­u­larly for Euro­pean and Asia cus­tomers — care to share response times? Can you also share an opin­ion on the use of asyn­chro­nous script / func­tion calls and Omniture’s plans to sup­port this method?

    I’ll cer­tainly be encour­ag­ing clients to add this to their project pipeline.

    Cheers, James.

  • http://blogs.omniture.com/author/bgundersen Bret Gun­der­sen

    Excel­lent point, James. Omni­ture account man­agers are reach­ing out to cus­tomers over the next few weeks, to rec­om­mend this.

    Your account man­ager has access to aver­age response times by region, so I won’t list them all here. But to give you an exam­ple, image response times in the UK, mea­sured by Gomez and Keynote, aver­age 392 mil­lisec­onds with­out RDC, and 25 ms with. On the other hand, the net­work topol­ogy in Asia pre­vents quite as dra­matic of an improve­ment. Aver­age response times in Asia go from 547 mil­lisec­onds to 352. These will improve as we intro­duce more col­lec­tion nodes in that region.

    I’m glad you asked about the use of asyn­chro­nous scripts. The async flag is an HTML 5 fea­ture. Based on our research, the only browser that sup­ports asyn­chro­nous JavaScript is Fire­fox 3.6, which is still in beta. So using that flag now prob­a­bly won’t impact the speed of your site much. How­ever, we are plan­ning to include this in our stan­dard tags in the future, as HTML 5 becomes more prevalent.

  • Heather Aeder

    Do you have to be on H code to take advan­tage of this? Or will it work with G code as well?

  • Bret Gun­der­sen

    If you’re on first party cook­ies, you don’t need to touch the code on your site. It’s a very sim­ple DNS change.

    If you’re using 2o7​.net, we’ll trans­fer vis­i­tors’ cook­ies from 2o7​.net to omtrdc​.net, which requires H code. You may not be aware that ver­sion H of the JS file sup­ports ver­sion G page code, so you’d just need to swap out JS files in that case. KB arti­cle 1826 has a whitepa­per on how to use ver­sion H of the JS file with G page code.