ThinkGeo.com    |     Documentation    |     Premium Support

Performance and Scalability

#1

Hi,


I have a specific query wrt performance and a general query wrt performance and scalability.


Specific


I have a set of map shape files and associated data [~ 300 MB].


There are approx 6 layers, ie, roads, street boundaries, county boundaries etc


My initial intention was to create a separate layer for each and allow the user to switch these on an off in the overlay switcher but I had a concern about performance of using too many layers.


I then decided to separate these layers into 2 or 3 max. [Physical, Boundaries and Road/Street/ layers]. These would appear in the overlay switcher.


Is the performance of the above layout a valid concern?


I have 1 shape file layer at the minute [evaluation purposes] and 5 other Marker Overlays that are required.


Adding the 3 layers above would mean the following layers would be available in the overlay switcher



        
  • 3 base shape file layers. Although the street layer would only be available at increased zoom levels. Boundaries, rivers etc would be available at all zoom levels

    •     
  • 5 Marker overlays [InMemoryMarkerOverlay].


I can be careful to some level with the amount of markers displayed and I assume if there are 100 +  tiles in a shapefile layer that only the tiles within the extent are requested. Can you confirm that this is true.


General


For evaluation purposes I have a local file store with the maps and this [along with the pages is served through IIS].


This is probably not at all viable for a production environment where there could be anything up to 30 concurrent users accessing various instances of the map control across numerous pages in our web app. IIS probably would be the bottleneck. I noted some of the points here gis.thinkgeo.com/Support/Dis...fault.aspx and here gis.thinkgeo.com/Support/Dis...fault.aspx


Do you have any guidance as to what point a WMS Server needs to be considered. I note that your WMS Server Edition product is still in Beta at this stage.


An alternative strategy I believe would be to serve the maps via a Webservice/WCF service. Would this require a purchase of the Map Suite Services Edition product or are there alternative approaches.


Finally, have you any whitepapers on performance and delivery mechanisms for maps to the web Map control that I can reference.


Thanks,


Liam


 


 



#2

Liam, 
  
   Thanks for all of the information, it makes helping you much easier.   
    
     I think your performance concerns are valid.  For each overlay that you have it generates a separate set of tiles that get requested from the server.  This causes the server to work harder and the client to work harder.  On the client side there are more requests and more floating divs representing the tiles.  Of course performance is all about your objectives and what tradeoffs you can tolerate.   
   
 1. For the best performance I would suggest you set all the base layers as one overlay and not allow users to turn off sub layers.  This allows only one layer of base images to be requested and lowers the load on the server. 
  
 2. The next best thing would be to allow just a few variations.  For example if you allow them to turn off roads but treat it as its own overlay.  You would have one overlay that is Base + Roads and one that is Base without roads.  The user only has one turned on at once and they can switch.  In this way you only ever have one base overlay turned on.  This is similar to Google Map or other  providers. 
  
 3. You can pre-cache large areas of the base maps to let them download faster.  We do this for our World Map Kit WMS Server and online product.  For the first 14 zoom levels it takes us a few days, on a few machines, and about 3-5 gig of space to cache all of the tiles.  For lower zoom levels we cache tiles that are within US urban areas and towns.  This allows is to quick tile down to zoom level 16 or 17 pretty easily.  When the tiles are cached it relieves the load from the servers and makes fetch time from the client very fast.  If you have some specific areas that your users work in then caching might be even easier.  We can provide you some home grown tools we use if you want to do this. 
  
 4. Regarding the WMS server I suggest, if you have the time, to watch the video introducing it.  The video is on the product page under the video tab.  To recap there are quite a few advantages to using the WMS server when you need performance.  I will outline as many as I can below. 
  
 5. A WMS server solution allows you to separate the map generation away from the main set of web servers.  This may be important if you can handle the normal web load on one server but adding mapping seems to bog it down.  This becomes a problem because web request such as generating a report or saving a record to SQL has to compete with generating lots of maps.  Map generation is very time and resource intensive so if you can isolate it you are better off.  This allows your web traffic to other parts of the website to not have to compete with map traffic. 
  
 6. A WMS server allows you to load balance the map generation separate from your main website.  This is important because many times developers use session state and that complicates load balancing.  It also allows you to use different hardware for map generation versus your regular web traffic.  Many times only a single server is enough for the main web traffic but adding maps changes that.  Since the WMS server doesn’t use session state you can easily setup a separate and simple load balancer setup for the map generation that you can scale up and down without touching your main web server.   
  
 7.  The load balancing is important for mapping server because of inherit limitation of certain browsers.  In IE for example there is a limitation of two or three requests to a single server.  If you have three overlays it could generate up to 60-100 requests.  This means that even if the tiles are cached on the server your requests will be serialized to two or three at a time.  Many other browsers do not have this limitation but if you are allow your app to be accessed by IE then this is a real concern.  In having more than one map generation server you can really boost tile serving throughput.  What we do ourselves is we have four public load balancers IPs that point inward to just a few machines allows us to scale the number of machines up or down.  In this way we can server many tiles at the same time to IE and this works pretty well. 
  
 8. A WMS Server also allows you to re-use your mapping logic on different delivery platforms.  What I mean here is that currently you may have a web client but with a WMS server the maps would be accessible to desktop or mobile clients as well if you wished.  You effectively isolate your map generation and you can consume it in any of our products on various platforms. 
  
 9. The technology in the WMS server allows you to server maps faster than in the web edition.  In the WMS server we have a concept of a map configuration that you setup for a certain set of maps.  The WMS Server will create as many of these as it needs to handle the number of requests in relationship to how many cores the machine has.  In this way we can be very aggressive with utilizing all the resources of the machine because we assume it is for the single purpose of generating maps and serving them.  In the Web Edition we have to live in the rest of the ecosystem and be more conservative.  In addition we know that the WMS servers maps are less dynamic, though we do support dynamic maps, we have special logic for static maps that allows us to generate them more efficiently. 
  
 10.  Many people are scared away by WMS servers in general.  I can’t blame them as typically their experience is that they are really slow or don’t work very well.  This is in part due to the nature of the WMS specification and the disregard for public WMS server on the web.  First the WMS specification assumes that all of the maps can be generated at any scale.  This means the maps can’t be cached so they are always generated on the fly.  This is so resource intensive and wasteful it makes most WMS server extremely slow.  Secondly many groups publish public WMS server which are quickly overwhelmed by the demand.  Since they are free everyone uses them and it brings them to their knees.  When we designed our WMS server we did it to answer scalability scenarios in our products and did it with performance in mind.  With the advent of Google Maps and the concept of 20 or so pre-defines zoom levels it allows us to cache the tiles at certain, user defined, scale so when you use our tiled WMS server with our products you cut through many of the shortcomings of traditional WMS servers.  WMS as a specification doesn’t address security and this is something we handle extremely well in our solution.  This meant that if your URL got into the wild there was no way to stop people from using it.  We have examples of various security and throttling techniques in our product that handle this. 
  
 I would suggest that for scalability and performance that you consider the WMS server setup.  It is going to perform better and be much more turn-key then trying to develop your own WCF service.  The product is currently in beta however I believe that it is very stable and we have some large customers using it.  We have gotten quite a bit of feedback since we released it I feel the bulk of the changes are behind us.  It would probably be in production now however our policy is that we have all of our releases synchronized on May 1st and November 1st.  This allows our customers to rely on those dates for planning and ensure all of our products are in sync with each other as many of our customers use multiple products.  I would also suggest if you are still uncertain that we setup a call and discuss it.  Sometimes it is easier to answer questions over the phone and I may be able to get a better picture of what you are trying to accomplish. 
  
 We are preparing some whitepapers to be release with our new Wiki.  As the product is in beta now we were waiting to make sure things get flushed out before we went too far. 
  
 David

#3

Hi David, 
  
 Thanks for the extremely comprehensive reply.  
  
 The advice on the base overlay makes sense. 
 Our customers will access the web app internally only and most of them will be on IE. 
  
 [Noted on the WMS product being ready to leave beta and on the release process you have in place.] 
  
 Best Regards, 
 Liam

#4

Liam, 
  
   If you users will be on IE then I highly suggest that you go the WMS server route.  In that way can setup multiple boxes for your tile server and get around the IE limitation.  Otherwise you need to load balance your main site and you may not want to do that.  With WMS you do not need to have a load balancer specifically you just need to specify in the configuration of the server that you have multiple servers.  You can also specify on the WmsRasterLayer multiple server IPs and it will divide the requests between them which will really speed up IE.  You can see the limitation with IE at the site below, on the server side  for us when people use IE it is so easy to tell as the requests queue up two at a time.  After looking back at the article it looks like IE 8 ups the limit to 8.  The article below shows how you can change the value, you can play around with it and see if you get better performance.  You will see a big improvement once you get multiple servers with many cores in the mix especially if the data is cached, it is almost instant. 
  
 support.microsoft.com/kb/282402 
    
 David

#5

Liam, 
  
   One other quick thing is that between release we support all of our products through our daily public builds.  If you run into an issue that needs fixing we can fix it and the build get automatically released through the customer portal.  I was not sure if you were aware of this.  It allows us to do quick turnaround on most bugs and new features between major releases.  Let me know if you have any questions about it. 
  
 David

#6

I was thinking… 
  
 if i have for instance: 
  
 map1.example.com 
 map2.example.com 
 map3.example.com 
 map4.example.com 
 map5.example.com 
 application.example.com 
  
 the application will request the maps to different subdomain, this way the browser could fetch 10 tiles each time. 
 But is this possible with webedition, 'cause i was seeing the requests made and it seems the map needs the reference to the page. 
  
 BBOX -93925051.334331,-15738952.157235,73898897.566611,13794312.593489 
 CACHEID  
  CLIENTID MapControl1  
 EXTRA 200942294229 
 FORMAT image/png 
 HEIGHT 189 
 OVERLAYID 3254 
 PAGENAME MapViewer 
 SRS EPSG:4326 
 STYLES  
 WIDTH 1074 
 ZOOM 0 
  
 and the SRS EPSG:4326 in my case doesn’t seems to be ok. But maybe this is a miss configuration. 
  
  
 Does the map control uses some how the Session?

#7

Rui, 
  
   If we are just talking about the Web Edition then you have two choices.  If you use session state then if you have multiple server they need to be load balanced to one URL and that load balancer needs to know that if sends requests back to the same server.  So in that case you would not get many tiles returned at one time.  The Web Edition also supports non session state scenarios such as using SQL Server.  In that case you you still need one URL but if you use FireFox or Chrome then it will make the request to multiple servers at once, IE will still be left using its queue. 
  
   That is why I suggested the WMS server.  In that case you can use session state for the main server like application.example.com.  Session state is easier for developers many times and allot of internal web apps don’t need many servers.  Then isolate the rendering to the WMS Servers, in that way there is not any requirement of session state and you can scale that up or down without a load balancer or SQL Server.  It is also IE friendly…   
  
   Allot of it has to do with what kind of resources, expertise, and requirements you have.  Once you know the constraints and requirements then the architecture usually pops out.  Please don’t be afraid to ask questions, correct me etc on this.  I think this is an extremely useful thread.  It is the kind of thing we need to move to the Wiki once it is out. 
  
 David

#8

Hi David,


Noted on the IE behavior, Thank your for the further clarification. The link is a useful reference.


Also on the daily builds. Its good to have that option.


I agree that its a useful thread also. It has clarified a few key concepts for me. 


Liam



#9

Hi Rui, 
  
 I think the WMSOverlay can fit your requires about consuming several subdomains for one time. The ServerUris property allows you add all subdomain URLs to it, and the tiles of the layer will request the images from any of the servers randomly. 
  
 Thanks, 
 Johnny 
   


#10

Yes Johnny, that’s it. But for that i need the WMS Server? I can’t do that with WebEdition, can I?

#11

Sure, we need WMS Server to balance the press to several servers to improve the performance. To manage that, you need WMS ServerEdition besides WebEdition. Currently, we are unable to manage the scenario “Subdomains” just with WebEdition. 
  
 Thanks, 
 Johnny