In this white paper we will examine the performance of MapLarge API tile servers under real world load scenarios. We will also quantify some typical consumer use cases and estimate server requirements for a typical multi user load.
OutlineI. Why Response Times Matter II. What is a "Real World" load? III. Delivering Fast Maps IV. Dynamic Response Tests V. Cache Response Tests VI. Load Capacity Conclusions detailed article on user experience.
Page Load: Google Plain Base Map (34 requests 1.4 sec load) vs. Map with MapLarge API Data Overlay (58 requests 1.9 sec load)
Dynamic Requests - Expect 10 Requests Per Second Per UserAnalysis of the usage patterns of consumer maps hosted on the Map Large API shows that the typical user engages in bursts of panning, zooming and clicking activity. When first engaging with the map, users generate bursts of activity as they pan and zoom to an area of interest and several smaller bursts as they explore a more detailed area and click on items of interest. The level of consumer engagement will vary by use case and the best way to measure is to watch the load generated by users actually engaging with the map. The figure below depicts four example use cases and the http requests involved. In each request the initial page was loaded first and the request log cleared so that the FireBug logs below show the additional http requests created as a result of user interaction with the map. Google Maps and MapCancer made only map related requests and showed fewer requests, and Zillow and Hotel Map Search made additional requests to load content around the map like images of homes or hotels. The average use case session lasted 30 seconds to a minute and involved 300 to 400 requests or an average of about 10 requests per second during an active user session.
Load Created: Hundreds of requests by one user doing a task
Handling the Load - Page Load is Easy - Interactivity is hardDelivering static content under load is a fairly well understood problem. Most large sites use Content Delivery Networks (CDN) to offload larger static files from their dynamic servers and their dynamic servers also cache content in memory or on disk. This system works well for caching the files needed for the initial load of a map because every user of the page requires the same file and the system can simply cache the files in memory or on a CDN. Caching starts to become problematic as web 2.0 applications allow users to dig into deeper datasets and begin to generate dynamic content queries. Caching every permutation of every unique query could easily swamp the memory and file system limitations of most dynamic and CDN servers. Complex interim solutions are possible, but the ideal solution would be to have dynamic servers fast enough to handle millions of unique queries on the fly.
Estimating Dynamic Load - How many unique requests can we handle?Delivering fast, interactive maps of large datasets to users is the challenge the benchmarks below address. The dataset used for the test below was a 58mb database of over 140,000 hotels with attributes covering price and other metadata. The icons were dynamically shaded by price using the attribute field "LowRate". Our Web Mercator tile format is compatible with all major base map vendors including Bing, Google and ArcGIS. All info about the map is conveyed in the url and you can experiment with different values here Example Tile: http://0api.maplarge.com/Tile/Tile? x=4&y=6&z=4&filter= &layer=geo~dot~XY |data~hotels~LowRate &shader=method~interval |colors~LightBlue/Blue,Blue/Red |ranges~50/125,100/300 |dropShadow~true |textPre~x/3,y/3,size/9,text/$ |text~round/0,x/8,y/3 |shape~rectangle |fixedHeight~14 |size~30 |count~300
Hardware - Azure Small Instance - Single Core - Hit by external clients over HttpWe selected the smallest Microsoft Azure instance for these tests because they represent a nice baseline metric that can be easily monitored and scaled. The specs are as follows below.
Dynamic Tile Server Speed: 100 to 150 Requests Per SecondFor this test we monitored and logged CPU, Memory, Http throughput and server errors during a three hour run. Memory usage stayed constant, there were no errors. CPU usage was the bottle neck and http throughput was over 100 requests per second as shown below.
Hardware - Azure Small Instance - Single Core - Hit by external clients over HttpThis test also used a small Azure Instance (see specs above). A CDN or load balancer could also fill the role of handling cache responses in some circumstances.
Requests Per Second During Test: Min: 780 -- Max: 900As in the sustained test above, memory stayed constant and there were no errors. CPU appeared to be the bottleneck, and throughput was over 780 requests per second. detailed article on user experience, or contact us at info@MapLarge.com if you have specific questions.