I have focused a lot of time optimizing a system very much like Google maps, except for the exact opposite data set, extremely volatile data. Without focusing on the details of the project, this data could change every 6 hours, to ever 15 minutes. Being service oriented and the difficulty to visualize this dataset had us utilizing the OGC Web Mapping Service (WMS). However for large, extraordinary volatile data, using standard WMS requests just wont cut it for a high performance, highly active web applications.
What was the next step? Well being very familiar with Google Maps and Google Earth solutions, lets understand the simplified problem Google has reduced web mapping to. Predetermined zoom levels, with a Tile Pyramid request schema (see Custom Map Types documentation ). So the next step is to manipulate the WMS services to implement the same request scheme. With this scheme you can now cache tiles and get the speeds that you see on Google Maps once they are cached.
[ilink url=”/java/ehcache-and-terracotta-for-the-enterprise-caching-solution/” style=”info”]See Enterprise Caching with Ehcache and Terracotta[/ilink]
Was this good enough? Of course not! Optimize, optimize, optimize! Well you know a user will not request one tile, they will undoubtedly request all the surrounding tiles. So lets start generating and caching the surrounding tiles on a cache miss to get ready for that next request. [quote]The improvement was overwhelming![/quote]Cache misses were reduced from ~25 to ~5 (depending on the browser and other conditions). The overhead on the server for cache misses was increased, however to produce a larger image and cache smaller tiles is easier than to produce the small tiles per request.
These enhancements bought a ton of time for the project, and with the feature enhancements, started to make the project successful. Was it good enough though? Of course not.
Whats the next biggest link in the chain? Browsers only allow a small number of threads to download resources per domain. IE 7 and below ~2, Firefox and IE8 ~4-6, Chrome ~8. Well that’s not a lot to download hundreds of requests in seconds. There ends up a lot of queued requests that may be old. Don’t ignore simple proven solutions. Implement multiple domains! tilingservice1.domain.com, tilingservice2.domain.com etc. This is the age-old trick to fool your browser into opening more threads to your server. This was huge! But keep pressing!
Well lets see… Hundreds of thousands of round trips from client to server, no matter how fast, add up, and doesn’t get better over time. Basically the problem becomes less and less of individual response time, and more and more on throughput of image tiles. Enter the world of proprietary solutions.
Here you start to enter the advanced world of real-time message protocols (RTMP). Good luck finding a web mapping system that’s tightly integrated with an optimal RTMP. Now the solution is to implement lots of timer delayed processing on both client and server:
Client – Tile request capturing. Capture as many tile requests in a small amount of time to send a SINGLE request for ALL the tiles with a completely asynchronous call.
Server – Aggregate requests. After filtering out all cache hits, aggregate similar requests to create the known required imagery, cache tiles, and push those tiles out to the client(s). That push should be a single push of all available tiles down the client, reducing what use to be thousands of round trip requests to just a few (or a few with a lot of pinging on the server for those long pulling solutions).
You will need a way to capture the tile on the client and direct to the proper location on the screen. There is no current standard existing for this (if possible utilize the URL but sometimes that can’t be assumed).
So now we have gone from an OGC standard (WMS) that can be utilized by many systems, but just isn’t fast enough, to the most proprietary system of a complex network communication, RTMP, tile generation, and enterprise caching. Do you feel like you have done something wrong?
Don’t! You have done good. Looking back at the experience, the business men ask, if the research was done in the first place, could you have saved a lot of time and made a lot more progress quicker? Maybe, but who would have known the need for speed would have been so high? Each one of these steps bought many months of time in which the system out performed itself many times over. As more features and more data sets were developed, more speed was needed.
Look at what you have. You now offer many services, through all different protocols: ad hoc WMS, Tile Pyramid requests, your RTMP implementation, multiple domains for speed, and you know your cache on the back-end has been put to the test. You have a wide data set which requires high-speed, multiple ways of achieving that speed, all of which feed each other in the caching game.
What’s next? Well to be honest I am not sure. Image compression to reduce bandwidth? Hardware solutions to increase available bandwidth, and cloud caching? Give up and only offer vector data and let every client re-visualize the same datasets 10 times over? There are tons you can do. I feel confidant in saying that the above are the best improvements that can be done to your web mapping services for quick, huge performance increasing.
Let me know your stories.
