To cache or not to cache

A colleague recently asked us about offering some advice on delivering a fast web service  to a client who was using a combination of ArcGIS for Desktop and the web. The datasets are from the Ordnance Survey’s OpenData offering.

 

 

The datasets included:

1. OS Street View.

2. OS Vector Map District.

3. OS 50k  Raster.

4. OS 250k Raster.

5. OS Miniscale.

 

Their challenge was working out whether to deliver a cached map service to a client, a dynamic map service or a mixture of a cached map service and the original data as a Geodatabase? The issues he needed to deal with included the time it took to create the map caches versus performance versus utility versus cost. A multi-layered issue but ultimately it boiled down to answering the question ‘to cache or not to cache?’

Actually, his question was answered initially by another question, why bother? Consider signing up with Esri UK’s free cloud-enabled map services and become productive immediately. Leave the caching work to us. This is a route that a lot of organisations are already doing and Esri UK has been happily serving up fast, visually pleasing map services since the service went live in late 2011. However, the client in question was ‘air-gapped’ and could not connect to the internet for security reasons.

So back to the original question. Our recommendation is that it’s often best to cache your data rather than serve it out dynamically.

Server Performance

The resultant CPU and RAM for serving a cached map is tiny compared to the very CPU and RAM intensive operations of rendering the same image dynamically. Most applications will be unable to scale up to heavier use if the base map is not cached.

A map service that is cached can therefore scale very easily as more and more users are added.  Esri UK’s cloud-enabled map services are happily serving a vast number of map views a month and a high level of concurrent users with little effort.

A dynamic service would be unable to get close to the performance of a cached map service as users increase. Parity between dynamic and cached map services exists only at very low levels of usage, say one user. Also, LocalView Fusion[1] templates are designed for cached base maps and some functionality is limited when a dynamic base map is used.

Architecture

There are also architectural differences when using a cached map service:

 o   A web browser can cache tiles it has requested previously, thus reducing the number of hits each client makes on the services over time. Similarly, most users may have some sort of cache or proxy server that also performs the same task but at the network level.

 o   Web servers are designed and optimised for serving lots of files off disk and/or memory; it is how web apps should work.

 o   By comparison dynamic images usually involve a number of resource intensive tasks including: data search, results retrieval, image generation, disk I/O to save the image to disk (even when streaming as MIME[2]) and other such steps.

Other Considerations

Of course, a cached map service isn’t a magic bullet to all of one’s requirements. There are a number of issues to think about: 

  1. Time: One needs to spend time (in some cases, a lot of time) to produce the map cache. The process is dependent on many factors: the number of scales, image type and resolution to pick out three. With the need to potential roll out updates quickly, cached map services may not be the most agile option.[3]
  2. Size on disk: Disk space usage will be a concern as a map cache can take up a significant amount of space. The Esri UK map services currently have a disk foot-print of 3 terabytes (and growing) – all this has a cost in storing and managing.  
  3. Caching Processes: Resources required for creating cache – multi-servers may be required to reduce time but it increases cost. Faster servers may need to be provisioned.
  4. Update Frequency: If the data changes a lot, then it potentially means there is a need to re-cache the data; either all of it the changed portions. Workflows need to be developed to enable this introducing an overhead.
  5. Less Dynamic: If a client needs to perform client side processing such as online digitising, dynamic rendering of layers or some other function; a map cache may not be suitable.
  6. Scale limits: The largest available scale of a map cache may not contain enough detail for certain workflows and organisations.

So in some cases a more subtle and nuanced workflow may be needed such as combining the advantage of both dynamic and cached map services. For example, a client may require data to be available down to 1:500, 1:250 or 1:100 which is just not practical to build map caches using current prices and resources.  So a viable solution would be to use vector data from a File Geodatabase as a base map for these scales, then utilising cached raster maps as the base map once you’ve zoomed out far enough.

For those interested you can see the cache levels and hardware specifications we typically use for building national caches here.

 


[1] Esri UK’s Platform-as-a-service offering

[2] http://en.wikipedia.org/wiki/MIME

[3] Though many options and alternative workflows exist to maintain a continuously changing map cache; we will explore some of these options in future blog posts.

[4] http://aws.amazon.com/ec2/instance-types/

Cloud computing at Esri UK

ISG (Internet Services Group) has for the last six years been managing Esri UK's hosting and web services both for internal and external clients. This was supported through internal and third party hosting suppliers.

The cloud offered a number of differences (I would not use the term 'advantages') over traditional on-premise hosting.

The on-going debate between on-premise and cloud solutions comes down to specific details and requirements within each organisation. The decision to go with one or the other solution should be made only after reviewing each organisation’s unique situation. Cloud computing offers a lot but it should not be regarded as the magic bullet.

ISG started off with an on-premise model but over time migrated towards a cloud-computing infrastructure as provided by Amazon Web Services (AWS) and taking advantage of the utility pricing model where one only pays for what one uses. When a server or resource is not required, it is turned off saving money both in terms of management and power. There is no need to pay for excessive capacity.

AWS had been working with Esri Inc to create ArcGIS Server Amazon Machines Images (AMI) - which are pre-created ArcGIS Server 10.0 virtual machines running on the AWS cloud. ISG have been using these AMIs, editing and reconfiguring them for our specific requirements and commissioning them for use. For ISG, the cloud has meant that managing hardware and software with a small team, isn't such a time consuming task anymore. Gone are the days where one needs to travel down to our hosting centre to change disks. The headache of hardware upgrades are now a thing of the past as AWS continues to add and maintain the underlying hardware. 

For Esri UK the PROS and CONS of a Cloud model of service provisioning include:

PROS:

•Lower Total Cost of Ownership (TCO) - certainly, the cost to the business of setting up a hosted service has dropped dramatically. In the past, even before the first user - a hosted solution would have cost upwards of £1,000s to setup. Now, a few days of work and the service is usually ready.
•Scalable performance to fit business’s needs. If a service has seasonal peaks (i.e. an online conveyancing service or a charity web site) then the ability for the resources to expand in terms of size and power as usage demands it becomes a big plus for us. Resources can be added almost instantly. In the past, one had to purchase extra hardware which would become redundant after the initial peak requirement. The cloud grows as big and as quickly as demand requires or conversely, can shrink down to a minimum. Saving in cost all round.
•Reduce upfront costs on hardware and software means that ISG does not need to spend days working up estimates on hardware costs and maintenance payments.
•Higher server availability and recovery. If one server fails, it is automatically picked up on another server assuming a copy of it was made. Usually, this new server can be online within minutes. Even higher availability can be provided if the solution involves clustering and load balancing.
•Utility based. With a cloud solution we will only pay for the amount of server resource we need and pay for them on a monthly basis, like electricity.

Hosted CONS:
•Bandwidth costs could potentially be very high if user numbers prove incorrect from estimates.
•Not all software programs can be moved into the cloud.
•Depending on the size of the client, it may not be a great price difference between cloud and on-premise.
•Security can be a concern. If a service or a client has specific security requirements, it may not be able to move to a cloud-based solution.
•Downtime. One is completely dependent on the Internet and service provider. If the Internet is down, service could be offline. The risk is of failure is there but it is borne by Amazon Web Services[i] rather than ourselves.
•Continuous cost, after the initial pain of capital expenditure - the cost of running an on-premise recedes to a background cost of staff salary and core infrastructure costs (power and light); it becomes an asset that depreciates in value. With the cloud, one can have a variable and continuous cost that may be difficult to predict. This can cause issues with budget forecasts and estimates for the business.
•Even for simple demonstrations, testing etc - one still has to pay. One doesn't have an 'old' machine handy to load up a test environment.

Since there are several PROS and CONS to hosted models and on-premise models, ISG has found a compromise in a hybrid solution.  A hybrid solution for ISG means that some of our resources are still on-premise (a combination of physical, virtual and internal cloud resources) these are used for testing, demonstrations and for specific clients. Our production/live services are now cloud-based giving us the best of both worlds.

A lot of other areas need to be discussed such as the relevant performance of disk I/O between  cloud resources as opposed to a physical on-premise resource. Security is another large area of concern as well as the necessary changes in one's working habits.

I guess that's for another time.

 


[i] http://www.zdnet.com/blog/foremski/the-irony-of-a-cloud-knocking-out-amazons-ec2-cloud-services/545