This is a guest post from my friend Dave Williams at AECOM. Dave is one of the smartest GIS Systems Architects that I have ever had the pleasure to work with. He has deployed some very fast on secure web mapping applications on the very challenging network environments of DoD. Dave can be reached at DaveBWilliams@gmail.com.
Your Web Map's Secret Weapon
How pre-rendered content and content delivery networks can better your program.
Dave B Williams
THE ICEBERG PRINCIPLE
I liken a GIS to an iceberg. Most people only see and interact with 15% of what comprises the overall system. For an iceberg, the 15% is what is visible above the waterline. For a GIS it is what is published to the Web and in most cases this is a map.
Ensuring that your users have a positive experience when interacting with your map is tied to known aspects of your product: user interface, content, accessibility, availability, etc. Anything missing? Speed! Other than having the data that people are in search of, the performance of a web based map is the single most important aspect to the successful implementation and continued use of a web based map. I base this statement on over ten years of both scientific and anecdotal observation of users interacting with web based maps.
GOOGLE: THE PARADIGM BUSTER
The release of Google Maps in February 2005 changed GIS. Your average non-technical person now had access to extremely fast performing web based maps in a simple and easy-to-use interface. GIS was now ubiquitous. Everyone was using Google Maps and the expectations about how a web based map should perform had changed. My clients now expected (and deserved) web based maps that were fast. Google maps (on .com) now became our performance target even for encrypted and complex systems supporting military operations. These mil networks are often very unstable and high latency.
THE PERFORMANCE OF GOOGLE ON .00001% OF THE BUDGET
I have no idea what Google spends on their mapping programs but we do know that Google is a >$100 billion dollar company with very deep pockets. We also know some of the key reasons why Google is so fast: pre-rendered content, distributed content delivery, and network tuning. Learning from what makes Google fast, how can a County or Federal GIS program provide services as fast as Google and within budget?
1. Pre-Render your content - This cannot be overstated! Pre-Rendered Content (PRC) means that when your users request a map at a certain zoom level and extent they are actually requesting pre-rendered or pre-processed map tiles. Your browser receives these tiles as known URL based resources. They ARE NOT passing a request to a spatial processing engine to query a database and build you a picture. Pre-rendering of content is accomplishable with a variety of tools including ArcGIS Server. ArcGIS Server also supports pre-rendering of 3D (globe) map service data. There are also open-source and WMS based pre-rendering tiling applications.
The server-side pre-rendering of your map content is the single most important thing you can do to improve speed and availability of your web mapping system.
2. Geographically distribute your content - It's a simple concept: the physically closer your map tile content is to your user, the faster they will pull it down. Distributed content delivery networks (CDNs) provide this capability. Akamai (http://www.akamai.com) is the industry leader in this. They have roughly 25,000 web servers distributed around the world. As content is accessed by users, it is cached locally so that other users can now access that content faster than going back to origin (your web server). I have implemented Akamai based solutions for a variety of clients (mainly DoD). The performance and scalability benefits are staggering. As an example, one client out of Atlanta, GA saw an 18x improvement in rendering speed when serving their main customers who reside in Southwest Asia. This type of improvement is a game changer. As another example, I support another program where all map tile content is on the Akamai networks. You can turn off the local web server and the map tiles still make it to the user as they reside within Akamai cache. This is the ultimate move towards uninterrupted availability.
Graphic Credit : http://www.akamai.com/html/technology/products/dsa.html
In addition to Akamai, there are smaller industry CDNs but one of the most interesting related technologies is Amazon's S3 cloud storage service (http://aws.amazon.com/s3/). S3 is an easier entry (lower intial cost) product compared to Akamai but it offers some of the benefits of a true Global CDN by leveraging the massive Amazon backend storage and delivery infrastructure. I completed a small project using S3 and map tiling and the performance was exceptional and significantly improved over hosting the map tiles on a local server.
3. Network Tuning - In addition to the distributed CDN capabilities that Akamai offers, they also support improved network routing and decision making. As your user types in your URL or makes a map request, Akamai intercepts these requests and makes decisions about TCP/IP routing that is almost always an improvement over letting your ISP(s) handle this decision making. This can be illustrated by running traceroutes against Akamaized and non-Akamaized URL assets and viewing how many fewer network hops occur when Akamai is involved. This also means that even if your content cannot be tiled and cached and that origin requests must occur, your users can see dramatic improvements in performance and availability.
How much does all this cost? Well, many people already own ArcGIS Server so let's not count that cost. If you don't , there are open source tools to create and exploit map tiles (Open Layers, etc.). Amazon S3's pricing is available here - http://aws.amazon.com/s3/#pricing and with a 15cents/GB storage cost and 1cent/1k request model, it is pretty cheap. The entry level Akamai pricing is roughly $4,500/month for less than 2TBs of monthly bandwidth use. This price includes their TCP/IP optimization and other related services. There is also the additional labor and workflow costs of creating tiles. This cost is high in the beginning but slows down once in maintenance mode as only select tiles need to be updated. I don't have hard numbers for labor costs/time per tile but I can relate that on one large on-going project I have one person who manages all of the tiling for worldwide imagery in support of high resolution mapping of over 500 airfields. He does this on one older 2-processor Pentium box.
In summary, map tiling makes your maps faster. Distributing your tiles via content delivery network makes them even faster and more stable. By leveraging the best technologies that our industry provides you can see Google-like mapping performance that does not cost much more than is already required to support basic dynamic services.