South Pacific Web Mapping

Some of my sites are hosted in Kansas City,MO which is a common location for many large data centers in the US,  Kansas is a popular place for building data centers because it provides equal network latency for both east and west cost clients due to its central location (latency depends on the length of the actual link, i.e. how long is the transmitting optical fiber cable).

Kansas City was initially built because of the strategic confluence of the Kansas and Missouri rivers that provided good steam ship transport through the Mississippi-Missouri river.

Kansas City 1869

Being a large population center on the river it had one of the first major railroad bridges across the Missouri  which made the city a major south to north east to west railroads hub

Once the optical fiber network infrastructure used by the core of today’s Internet was build, the public land of the railroad grid has been utilised for laying out the cables making it the new communication highway, Kansas once again became a major network/data center hub (all of this because the same bridge on the same old river..)

(source: colocationmontreal.com).

I am currently running most of my response time and web latency tests from Dallas and Kansas which provides extremely reliable results giving the infrastructure and location of those data centers.

The Google GMail Team came up with this one for solving latency issues on mobile based apps:

http://ajaxian.com/archives/gmail-mobile-latency

This one speeds the loading of a mobile web page + full parsing of  the interaction layer(Javascript) from 2600ms to 240ms (10 faster!!) on the same script block size(200KB)!!

Worth trying when customising web apps for moblies (which has good 3G bandwidth but really bad  latency due to the transport over microwave).

During the last four years I have been using JavaScript frameworks across many of the sites I have been developing, I found the Mootools syntax and object oriented approach to be the most intuitive to code with and JQuery to be the easiest to integrate with additional existing JavaScript libraries (with its excellent NoConflict mode).

When it comes to creating front-end functionality for integrating with ASP.NET, JQuery is definitively the framework of choice with its full Visual Studio integration and recent Microsoft’s support.

One of the main drives for utilising JQuery will be latency optimisation, where the entire load for functionality and client side validation could be offloaded for CDN delivery, reducing network delivery overhead.

This approach could be demonstrated with a recent implementation I have been involved with (see below) :

view the site

where a heavily requested travel sites is optimised for a quick initial load time with extensive client side validation, reducing server load and minimizing network communication (and its potential latency overhead).

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