South Pacific Web Mapping

Late last year Google announced that the next major update to the Page Rank Algorithm (search result indexing) will start taking into account the pages load (response time) see below:

This is introduce a major challenge while developing and hosting NZ/AU based web application, which many believe could be addressed using the following delivery techniques:

1) Identify your main landing pages for your primary key terms and define the most frequently managed content (banners, specials, news etc.) and push the container HTML out to the cloud managing the content using iframes or content deployment technologies (such as SharePoint).

2) Using more frequently updated pages with heavier functionality as link juice back into those primary fast loading landings pages.

3) Its been confirmed that both Bing and Google will not penalize on repeating content within sub domains (e.g. nz.mysite.com and au.mysite.com) allowing regional content and location related functionality to exist closer to its potential audience while containing similar data and templates.

4) Following the Latency Recommendations for AU/NZ based web pages for minimising the response time only to the one introduced as a result of router hops and distance.

2010 will be a good year for optimising South Pacific content, ensuring high ranking on future mobile device based search results(these will have only five relevant winners on the first page ;o)

Had an interesting biz tour in Seoul last month, pretty amazing growth in terms of GDP and Internet usage, once there LG and Samsung seems to be just the tip of the iceberg when looking into the local devices, service providers and wireless data infrastructure.

web mapping capabilities and internet UI (animation and front-end stuff) still has lots of potential giving the fact that the local script (Hangul) is all left to right with a nice reasonable 24 character set.. and could run Joomla almost out of the box!!

I have done a few speed/load tests from downtown Seoul, lots of router hops on a really good link, latency to NZ/AU was pretty big though..

Had a bit of experimenting on multihoming using BGP, the main idea is using BGP4 to announce an address space to all upstream links out side the autonomous system (AS) . This is particularly good for scenarios where a routing path requires high availability (allowing swapping of a cluster while serving web requests from different data centres with no down time), but is also experimented for load balancing global resources (serving the same web content from different locations).

I have got into BGP4 from my work on GeoWeb apps a few years ago when I realised that with BGP4 and dynamically created routing tables you cannot rely on IP address alone for identifying a requesting connection’s physical location (see here).

The bottom line is that when coming to implement a fast loading rich mapping solution(or any other mash-up), it is significantly important to know the client’s physical location (for serving content from closer locations) and  knowing its IP is not enough any more!!

possible scenario from a New Zealand Australia optimisation case(implemented within a Melbourne mash-up)

more on this

I am currently within the last stage of defining my research thesis in computer science, this research will address methods for delivering GeoWeb applications while minimising the effect of network latency on user experience.

This proposal is a result of practical experience in designing and developing web applications for the New Zealand and Australian Internet market for the last 7 years, the research aims to provide scientific evidence and methodologies for minimising the effect of network latency on the load time of web content (see my post on this subject here).

With the latest advances in response/load-time monitoring and measurements services, it is now possible to collect statistics of monitoring agents across the globe and identify network trends towards optimising web delivery according to the originating content requirements.

A typical web based map mash-up could potentially include HTTP requests from several different sources (content providers, storage distributors etc.) spanning across several continents, selecting the optimal resources during the initial load of the page (the DOM Ready browser phase) will be the primary factor for efficiently serving web content.

Within my practical professional experience I have been maintaining and monitoring over 110 servers while optimising the actual web applications running on top of those servers for delivering rich graphic content. This optimisation included usage of CDN providers, requests source tracking and progressive download techniques while monitoring the results from numerous locations around the globe.

A notable network monitoring solution that I have been using within my research since 2006 is Pingdom, which I believe is the only response time monitoring solution that exposes an API. This feature enables querying its worldwide monitoring agents counters for generating real-time, applications specific, global response time reports and statistics.

In February 1882 the Dunedin sailed out of Port Chalmers loaded with New Zealand dairy products targeting London’s markets while overcoming the distance limitations and utilising the latest cooling technologies, becoming the first commercial refrigeration ship ever.

I believe that with the massive move towards SaaS technologies powered by the growing IT Outsourcing/Cloud Computing trend, New Zealand’s prime location and unique IP routing link could play a significant role in researching ways for overcoming network limitations for physically distributed services.

On the arrival of the Dunedin in London 98 days laterThe Times commented: “Today we have to record such a triumph over physical difficulties, as would have been incredible, even unimaginable, a very few days ago…” which sounds very relevant considering the development of the internet today.

I had the honor to complete a web mapping project for the KiwiExperience which is New Zealand’s major operator of bus passes for travelers and backpackers.

This mapping solution included mashing up operators information and available bus routes throughout New Zealand with spatial data provided using the Google Maps API.

click to view map

One of the main achievements in this project was to provide a rich fast user experience while distributing content over several continents for users across the world, this was done by following the latency requirements I have posted last year through my latency research ensuring the optimisation of South Pacific content for international customers.

With the latest take over of Sun Microsystems by Oracle and the global economic slow down, the ability of web content originated from AU/NZ data centers to provide competitive user experience world wide will highly depend on utilization of cloud computing and resources.

A good example will be solutions where content is stored and maintained locally but where possible combined with resources available by content provider positioned closer to the Internets backbone (Tier I providers neighbors) such as maps and media available by Google, Akamai, Flickr and Data stores such as amazon (AWS/EC2).

Being involved in several VOIP integration projects in its early days I have noticed the effect of latency on voice quality and the ability to minimise this effect by locating the VOIP termination servers (where the signal turns from IP to PSTN circuit i.e. traditional analog line) as close as possible to the major target audience.

Following the rule of “make the product at its source but serve it from as close as possible to its customer destination.” has been used by traditional supply chains for centuries and still applies to the latest web architectures for maximizing your clients user experience.

Update October 2009:

The site has also won a Microsoft NZ Collaboration Award ;o)