Founder and Lead Developer of Macrotone Consulting Ltd.
5 minutes reading time (1024 words)

IP Mapping, clustering, refresh – performance impacts

ipmappingWe mentioned the other day about using HTML5 to determine a site visitors location and using it to be displayed upon a Google map. We are here looking at the various options that need to be considered when setting the parameters for the best ‘site impression’.  I have deliberately used the term ‘impression’ because most of the ‘work’ is actually performed by Javascript in the users browser. Each user will most likely be using a different machine, i.e. Desktop, laptop, tablet, smartphone etc., not to mention the different processors included in each type, and all these will different performance characteristics.  This each user’s impression of ‘how fast’ a site actually is, will be different, and this is without considering the impact of any network performance in a) obtaining the source data from the web site and b) the transfer of data to/from the Google mapping servers.

When originally introduced the IP mapping component  would fetch the source data from the web site and then populate the initial map, with clustering being applied if requested. Any further visitor information was fetched from the web site and then just displayed upon the map.  The ‘new’ entries were not added to any existing cluster and no new clustering was performed.  In addition any ‘old’ or expired entries, defined as such by a time limit beyond which entries were considered ‘old’, were not removed from the display.  The main impact of this was that after several hours upon a fairly lightly loaded site, a number of ‘individual’ map icons would tend to increase, sometimes significantly.  This was not considered a ‘bug’ or ‘problem’ per sec., since it was not envisioned that the map display would be left open for long periods of time.  How long a time was acceptable, might be asked, but this would be very dependant upon how many site visitors were being recorded and that is something that various tremendously between different websites.

One requested change was to enable continuous clustering, such that any ‘new’ entries were added to the already existing clusters.  This has been implemented but it carries with it an overhead in that the map clustering has to be recalculated every time a new entry is detected.  Exactly how long does it take you may ask?  Well again it is performed in the client browser so the performance of the browser and the network connections are important.  A second is not unusual when you have a very few items to cluster but this will increase the more and more items are added to the clusters. (Times themselves are difficult to be too specific about since they also very upon network connection speeds etc.)

One other change was to ‘remove’ from the map display visitor information that has ‘expired’ or considered to be ‘old’ or  ’stale’.  It was considered that one might implement a change to retain the ‘time’ the entry was obtained along with the entry information inside the browser and then get the browser to ‘clean’ up the displays by removing the markers from any existing clusters, or single markers.  When we investigated the time required to make the change, but also more importantly the time required by the browser to make the change, a different approach was decided upon.

Instead it was decided to implement a complete map display refresh feature.  Not we might add a web page refresh, just a refresh of the map itself and the information it contains. This effectively involves fetching all the ‘current’ mapping data from the website and removing all existing icon clusters and single icons and restarting from scratch building up the display.  The time required to do this was found to be faster than lots of small changes over the same period. 

So the IP Mapping component has a few time base settings:

  • A time that determines when a check should be made for new entries to add to the map display. 
  • A time that determines when the whole map display should be rebuild from scratch with the ‘current’ content stored in the database. Calculated and used as a multiple of the update time.

The ideal settings for these is very dependant upon how busy the specific web site is, in terms of visitors being recorded.  With one or two visitors a minutes then long time periods for the ‘update’ check might be sufficient, and the map display refresh might be every 60 minutes or so.  For a very busy site with hundreds of visitors per minute then shorter update periods might be desirable.  The map refresh time in this situation is going to be driven more by ‘how messy’ is the display starting to appear.

Note that the times specified are guides only since there is no way one can know how busy the browser machine is, and tasks in the browser are queued up for execution.

One persons view of what the ideal settings are, is not necessarily the same as another's and some experimentation may be required to determine the best settings for any given web site.

We mentioned at the start about the user’s impression, and this is something that has to also be considered. Do most of the site visitors use ‘relatively’ low powered devices. If so do you want to place a heavy load on the user’s machine by the map display refreshes/updates.  One can get some idea of the browser that a user is using from the collected data, which will give a clue as to the machine type.  Its not totally accurate but it is a guide.

There are no right or wrong answers to any of the above but they serve as a guide to the things that need to be considered.  Our own view is that we consider it unlikely that a visitor is going to be looking at the ‘visitor display map’, unless they might be a web site administrator of course, so an update frequency of a minute and a refresh of 15 to 30 minutes is probably as good a place as any to start.  Then fine turn to get to a situation that is ‘reasonable’ for a site.

Displaced anchor links when used with a fixed page...
Experiences with HTML5 mapping
 

By accepting you will be accessing a service provided by a third-party external to https://macrotoneconsulting.co.uk/

Go To Top

The Macrotone Consulting Web site would like to use cookies to store information on your computer, to improve our website. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our Privacy Policy.

I accept cookies from this site.