Reference Library - Performance Tuning

Performance Tuning

The following configuration items should be considered when optimizing system performance for a MapDotNet Server application:

Use of MapControlBridge

1. CacheBaselineMapState - if this property is set to true, then the map configuration (based on your selected MapID property) is cached in application state. The benefit is not having each user session have to access the map web service to download the baseline map configuration. The downside is any changes to your map configuration file will not be reflected in your application unless you recycle your application state. It may be helpful to leave this set to false during development and then set it to true in production.

2. EnableCompression - If true, all request/responses from the MDNS web services will be compressed. When the application and MDNS web services are on the same network switch this is not going to gain you anything as the savings in SOAP message size is counterbalanced by the overhead in compressing and decompressing the message. If the MDNS web services are accessed through a slower network connection, setting this to true may improve response times.

3. PersistMapRequestInSession - Determines if the MapRequest property instance is to be retained in Session state. This is by far the majority of state maintained in the MapControlBridge and setting this to false will reduce Session dependency to near-zero. You may want to set this to false for large-scale, high-volume applications where out-of-process session management is used. If false you will need to maintain your own map state changes and rebuild the MapRequest on every callback/postback. This can be done by reconciling changes against the baseline map state (singleton) stored in application state and then calling MapInitialize(myMapRequest).

Your application web.config

1. Load-balancing web service requests - you can add a line to your application web.config to specify one or more MDNS web services to load balance your map and query requests from the MapControlBridge:

See Load Balancing for more information.

For Virtual Earth Template II applications

1. Reload VE configuration on every tile fetch - by default this is set to true in the web.config
<appSettings>
<add key="ReloadVEConfigOnEveryTileFetch" value="true"/>
</appSettings>

This should be set to true during development so that any changes to your VE configuration table will be immediately reflected in your application. Set this to false in production so that the configuration information is cached in application state.

2. Preload your tile cache - use the tile preloader utility to pre-cache your tiles in the tile database. Make sure to use the overfetching override (e.g. -t6 creates a 6x6 [36 tile] map request and slices the tiles - the increase in performance is anywhere from 2.5 to 10 times) - make sure you do not use the -f (force refresh) flag with the overfetching flag! Otherwise the extra tiles over-fetched are effectively thrown out.

Please see the VE Template II documentation for more information on tile caching and over-fetching:

http://mdnsupport.ischosting.net/Documents/VE%20Template%20II.pdf

Your MDNS web services web.config

1. ReloadMapFilesXmlOnEveryRequest - when true this will reload the mapfiles.xml configuration file on every request so manual changes to this file are immediately reflected in your map files list. This may be turned on (set true) during development but should be set to false in production.

2. FlushMapObjectOnEveryRequest - when set to false, baseline map rendering objects are cached and cloned before each use. This should normally be set to false in production otherwise a new map rendering object is created on every request. This is primarily for internal use however there is a known issue with raster symbol images not cloning properly and in such cases this should be set to true. If 'false' you cannot use transparent GIF or PNG point symbols - applies to version 6.1.x and earlier.

3. CheckMapfileTimestamp - this setting tells the rendering service to check the timestamp of a map configuration file on every request. This should be set to true during development so that changes to your map file configuration will be immediately reflected in your map. Set this to false in production. If false, you must recycle your MDNS services state on any change to a map configuration. If 'false' you cannot use this MDNS service with the MapFile Generator.

4. UseSeparateThreadToDraw and SeparateThreadStackSize - use these only in cases where a stack overflow occurs from certain raster reprojections and where the default stack size (256KB on Server 2003) is insufficient. In most cases you may leave UseSeparateThreadToDraw set to false.

Your MDNS web services application pool on IIS6 and up

Make sure to place your MDNS web service in its own application pool without any other application or even any other instance of the MDNS web service and use the following settings:

1. Recycle after 60 minutes - because the services are stateless, periodic recycling will not adversely affect your application

2. Use a web garden if possible - if your server is hyperthreaded or multiprocessor - increase the web garden setting to match your processor count. Note: Do not use EPSG numbers in your map file or in a transform call (which will access the PROJ EPSG file on your file system) if you intend to use web gardening. Instead use PROJ4 transformation strings. This applies to version 6.1.x and earlier.

Last modified at 9/25/2007 7:50 AM by WEB\goisc