Optimizing your map configuration file is important for several reasons:

• Making changes to your map configuration file can dramatically improve Web site performance by reducing response time and increasing the throughput of the Spatial Server.
• Your users will have a much better experience if the map conveys the information they are looking for. The map must respond well, and it must not be overly complex at any scale. Your users will be viewing the map on an electronic device, most commonly a computer screen. You must take into consideration that the resolution of an electronic map is lower than a paper map.

The following checklist offers suggestions for improving performance, reducing clutter, and some best practices.

Checklist items	Comments
Examining the audience ___ Determine who the audience is for your service.	Before getting started, you must examine who your audience is. The information you provide in your map must meet the expectations of this audience. Features on the map must be easy to understand when viewing them at screen resolution. For example, if the map is a reference map, the geographic features such as cities or points of interest should be prominently displayed. If you are showing routes, the route must be easy to see. If the map is a gateway to other information using hyperlinks, the hyperlinks need to be clearly distinguishable.
Determining the display ___ List which devices you expect your users to view your map on. ___ Determine the expected screen resolution and size.	You have less space in which to present information in an electronic map then you would have for a map designed for the printed page. If you try to display all the information you are likely to overwhelm the user. The map may be too visually complex to easily comprehend. As much as possible, show only relevant information.
Assessing the configuration file size and time to publish it ___ Count the number of layers your map configuration file contains. ___ If the count is high, consider removing layers that are inappropriate for your expected audience. ___ Determine how long it takes for the service to start. ___ Determine how long it takes for all your services to start. It?s important to know how long services take to start when you reboot the system	Your map configuration size can contain as many layers as you want. The upper limit is a function of your computer's memory. However, as you add more and more layers, the map may become too cluttered for users to successfully comprehend. You should also consider performance. The more layers, the more time it takes to start a service. During this time, all Spatial Servers within the Virtual Server are unavailable for receiving requests. If you restart your services frequently, you should take this time into consideration. If you restart services only occasionally during off-peak hours, the start up time may not be as big an issue.
Adding projection information ___ Add projection elements to your map configuration file. For more information, see Adding projection information.	As ArcIMS services become more accessible, and many users want to combine data from different services, including projection information in your map configuration file becomes critical. If the service has an undefined projection, many clients may not be able to integrate the layers correctly. ArcMap requires projection information in order to integrate layers correctly. You must also define the projection if you plan to create WMS or WFS Services.
Setting scale dependency ___ In Author, visually set scale dependencies for each layer. For more information, see Setting a layer's scale dependency. Note: you should not use Author if you have previously hand edited your map configuration file. ___ As an alternative to using Author, set scale dependencies in LAYER in your map configuration file. ___ Test your service at multiple scales by zooming in and out. The amount of data presented at each scale should not overwhelm the user.	One of the best ways to improve response times is to set scale dependencies on each layer. If you make no other changes, you should be sure to set scale dependencies. As more and more features display, the processing time can increase dramatically. In addition, the map content becomes more cluttered and less informative. The proper scale for each layer is a judgment call by you. The layer must be comprehensible when viewed at the expected screen resolution. If a layer is displayed at a scale that contains too many features, set it to a larger scale. For example, it may make sense to set detailed streets visible at 1:25000 rather than 1:40000. In practice, setting the scale often involves making compromises between content and performance, particularly when the service covers a diverse area. For a consistent user experience, the amount of features displayed should be similar across all scales. Users should not be confronted with obvious gaps in the amount of data displayed or be overloaded by too much data.
Reviewing log files ___ Check the Image Server log file to see how many features are being processed for each layer at different scales. ___ If too many features are processed for a layer, change the scale dependencies. ___ Check that the data retrieval time is reasonable for each layer. ___ If using file-based data such as shapefiles or images, move or copy files to the Spatial Server machine for fastest data retrieval. ___ If using ArcSDE, ensure layers have spatial indexes; indexes can be tuned for better performance. ___ If using ArcSDE, create indexes for any columns queried in the ArcIMS application.	As you work on your service, you should review the Image Server log file to see how well your service is performing based on incoming requests. In the previous step, you tested your service by zooming in and out at different levels. Now you can check how many features were processed for each layer. In the following example, 258 blockgroup features were processed, and the data search time was .026 seconds. [time stamp] FEATURE LAYER: blockgroups (id= 0 ) [time stamp] DATA SEARCH TIME: 0.026000s [time stamp] SR FEATURES PROCESSED: 258 There is no one answer for the number of features that should be returned. The correct answer is relative to the type of data processed, its importance, and how clearly the data can be interpreted. While you are reviewing the log files, you may make other discoveries. In the following example, the streets layer (id=1) is taking over two seconds for data retrieval, which is the time to process and fetch features. [timestamp] FEATURE LAYER: streets (id= 1 ) [timestamp] DATA SEARCH TIME: 0.000000s [timestamp] GR FEATURES PROCESSED: 230 [timestamp] DATA RETRIEVAL TIME: 2.23000s If a layer takes an extraordinary amount of time to process, you should try to determine why. In the above example, only 230 features were processed, so scale dependency is not likely the problem. Another thing to check is the data source. Perhaps the data has many unnecessary vertices and generalization would help. If you cannot find anything wrong with the data, perhaps you can replace it with another data set or remove it altogether.
Setting layer visibility ___ Determine which layers all users should see when they first view the service. These layers should be turned on in Author. If you are hand editing your map configuration file, set LAYER visible="true". ___ Turn off all other layers. If you are hand editing your map configuration file, set LAYER visible="false".	One of the simplest and most powerful tools within an electronic map is the ability to toggle layer visibility. Not every layer needs to be visible by default like they do in a printed map. Users can start with a very simple map and add complexity as they see fit. Therefore, in your map configuration file, only layers that every user needs to see should be turned on by default.
Generalizing data ___ Determine if any of your data layers can be pre-generalized for faster display. ___ Include two layers in your map configuration file: one for the generalized data and one with the detailed data. Set scale dependencies so only one of the two layers ever displays. You can give both layers the same name so it appears to the user in the legend or table of contents that the same layer is always present. ___ If you discover important features dropping off your map display, add IMAGEGENERALIZATION.	Data generalization refers to the reduction of information contained in a dataset, such as removing the number of vertices used to define the shape of a line or polygon. The Spatial Server automatically generalizes data depending on the current scale. Before generalization, the Spatial Server fetches all the data from the database. Lines and polygons are then generalized and may not be displayed if they fall below the generalization threshold. Points are not generalized. In some cases, you may not want features to drop out at any scale. In this case, you can add IMAGEGENERALIZATION to your map configuration file. This tells the Spatial Server not to generalize features on any layer in the service. Use this with caution, because rendering times can increase dramatically since the data is not generalized. You can pre-generalize some of your datasets to improve performance by reducing the data fetching and rendering times by the Spatial Server. For example, if you want to display countries at the world level, you can create a dataset with generalized shorelines for display at small scales. The level of detail at this scale should be sufficient when you view the map on a computer screen. As the user zooms in, you can switch to a different data set that shows more detail. Data generalization is an editing procedure, and ArcIMS does not come with any tools to help you pre-generalize data. Tools are available in ArcView GIS and ArcGIS ArcEditor and ArcInfo. Some options available include generalizing line and polygon features, reducing the number of features, or creating ArcSDE group layers. In each case, the goal is to have a smaller data set that displays more quickly.
Displaying a subset of data ___ Use SPATIALQUERY where and SPATIALFILTER to create a definition query for each layer. More information is available in Adding SPATIALQUERY. Note that if you add SPATIALQUERY, you should not open your map configuration file using Author, or your edits will be lost.	You may have a data layer with thousands of features, and only a small subset are of interest to your audience. If this is the case, you can use a definition query to filter out unnecessary features. You can filter features based on attribute values, geographic location, or both. If you are using large shapefiles, and using a SPATIALQUERY takes too long, you may need to consider moving your data to ArcSDE. If you are doing just attribute queries, you can move the attribute data to a database and use server-side queries to search the database.
Reducing the number of attributes ___ If you are using shapefile data, determine if you can remove any fields from the DBF file when using the file in an ArcIMS service. ___ Use SPATIALQUERY subfields to limit the number of attribute fields available to users in each layer. More information is available in Adding SPATIALQUERY. Note that if you add SPATIALQUERY, you should not open your map configuration file using Author, or your edits will be lost.	Reducing the number of attributes available to ArcIMS users can improve performance and reduce clutter. If you are using shapefile data, you should consider reducing the number of fields in the DBF table to only those fields that your ArcIMS users need. The wider the table, the longer it takes for the Spatial Server to process requests. Regardless of whether you are using shapefile or ArcSDE data, you should consider allowing ArcIMS viewers access to a subset of fields in each layer and filter out those fields that are unnecessary for display. Reducing the number of available fields decreases the size of the response, thus improving performance. In addition, it removes clutter from your application because users see only what is necessary for making decisions.
Setting feature limits for tabular data ___ Use SPATIALQUERY featurelimits to limit the number of features that can be requested for each layer. More information is available in Adding SPATIALQUERY. Note that if you add SPATIALQUERY, you should not open your map configuration file using Author, or your edits will be lost.	You can limit the number of features that can be queried per GET_FEATURES request. If a data layer contains thousands or millions of features, you do not want someone querying for every feature. To avoid this problem and protect your site, you can set a feature limit to a reasonable number of features. Note that this feature limit is for retrieving the tabular data for a feature. The number of features displayed on a map is unaffected by this limit. For more information on feature limits, see Strategies for using feature limits.
Setting the search order ___ Use SPATIALQUERY searchorder to set the search order for ArcSDE layers. More information is available in Adding SPATIALQUERY. Note that if you add SPATIALQUERY, you should not open your map configuration file using Author, or your edits will be lost. ___ Send some GET_FEATURES requests to your service. Check the Query Server log file for processing times before and after you have changed the search order to see if the search order makes a difference.	If you are using ArcSDE data, you can set whether the data is first searched by attribute or spatially during a GET_FEATURES request. Performance can sometimes improve dramatically by the way the data is searched. By default, ArcSDE determines the best search order and may not be selecting the optimal method. In some cases, it is faster to search spatially first, and in other cases the data should be searched first by attribute. If GET_FEATURES requests seem overly slow, setting the search order may help. Changing the search order will be most noticeable on layers with thousands or millions of features distributed over a large geographic area.
Minimizing the use of labels ___ Determine which layers require labels. Street names, highways, and points of interest are good candidates. Remove labels from all other layers. ___ For each layer you label, make sure the labels are legible. ___ Check if the labels cover important features of the map. If they do, you can set the overlap attribute to true for a symbol to prevent labels from overlapping the symbol. ___ Review what label effects you have selected. If the labels legible without the effects, consider removing those effects. ___ Set scale dependencies for labels in Author. For more information, see Setting the scale dependency of labels. If you are hand editing your map configuration file, see the sections on SIMPLELABELRENDERER, VALUEMAPLABLERENDERER, and SCALEDEPENDENTRENDERER in Using Renderer Elements. ___ Check the Image Server log files for label rendering times. If the time is too large, consider changing the scale dependencies for labels, removing special effects, or removing the labels altogether.	ArcIMS allows you to label any layer in a map, but it is a good idea to label one or, at most, a few layers. On a printed map, labels, annotation, and text are integral to providing the user with detailed information concerning geographic features. On an electronic map, the user can access the information via tools such as the identify tool, and the layer may not need labels at all. Labeling many layers can result in longer response times because the Spatial Server must do much more work. In addition, too many labels can be confusing. Some features are important enough that they should no be covered by labels. You can set the overlap attribute to "true" for that symbol. Be careful that you set this attribute for the layer symbol you don?t want overlap on, not the label itself. Be cautious using this feature. If you set a polygon layer with no overlap, you likely will have few or no labels at all. Labels must be legible at screen resolution. Use the largest font size possible. Also, use sans serif, open-letter fonts. Special labeling effects such as glowing, drop shadows, background colors, and in particular antialiasing will have an impact on the total response time. Although these effects increase the total labeling time by a small fraction, this overhead should not be ignored. You can get an estimate of how long labeling is taking by reviewing the label engine time shown in the log files. [timestamp] LABEL ENGINE TIME: 0.015000s You can set scale factors for labels separately from the features. Labels do not need to display the entire time a layer is visible. Instead, you can turn on label visibility at a larger scale than feature visibility to decrease the amount of work the Spatial Server needs to do for every request.
Symbolizing data effectively ___ View your map at full extent. Features for each layer should be clearly and simply drawn. The table of contents or legend should be easy to interpret and not too long. Individual features should be easy to select. ___ Check the log files for rendering times. Check that no layer is significantly slower than any of the others. ___ Repeat the previous two steps at different scales. Make sure the map is not cluttered at any scale. If a layer overwhelms the map at a particular scale, consider changing the rendering scale dependencies for that layer.	Choose symbology that is appropriate for the scale. At small scales, use the simplest symbology possible, preferably by using SIMPLEMARKERSYMBOL, SIMPLELINESYMBOL, and SIMPLEPOLYGONSYMBOL inside a SIMPLERENDERER. Complex symbology at a small scale is distracting and can slow down image output time. Each part of a multipart symbol is rendered separately, so a four-part symbol is drawn four times by the Spatial Server. Using antialiasing increases the rendering time even more. Using raster markers and fills can increase processing time if many images must be placed on the map. Use unique or graduated symbols only at larger scales. Extra processing time is required when using a VALUEMAPRENDERER because the Spatial Server must access attribute data to render each feature based on its attribute value. Value maps can easily make the legend and table of contents unusable when many categories for multiple layers are used. It is not a good user experience to constantly scroll through the legend to find a marker. Therefore, use a VALUEMAPRENDERER on a layer only at scales when both the map and the legend or table of contents are comprehensible to the user. Since electronic maps are viewed on a screen, make sure the colors you select work in that environment. Subtle shades of color may look good on paper, but may be indistinguishable on a screen. Use greater color contrast, especially on the most important layers. If your intended audience is using a cell phone or PDA, you should minimize the number of colors and possibly use only gray scale colors.
Value maps versus spatial queries ___ If you are using VALUEMAPRENDERER to filter features in a layer, test using SPATIALQUERY instead. Check the Image Server log files to see which method performs better.	If you wish to display only a subset of features from a layer, use SPATIALQUERY rather than a VALUEMAPRENDERER whenever possible for performance reasons. For example, suppose at the full extent of the map, you want to display only major roads, which is only a small fraction of the number of roads in the layer. You could use a VALUEMAPRENDERER and display only these roads. However, in order for the Spatial Server to render this layer, it must still search through every record in the layer before drawing the features. This process can be time consuming. However, if you use a SPATIALQUERY, a filter is set on the layer, and the Spatial Server processes only those features within the filter.
Upper case field names ___ As a best practice, change all references to field names to upper case.	When referencing a field name in a database, performance is generally better if the field name is referenced in all upper case. Elements affected by this are CHARTSYMBOL,CHARTVALUE, DATASET, PARTITION, QUERY, SIMPLELABELRENDERER, SPATIALQUERY, TRUETYPEMARKERSYMBOL, VALUEMAPLABELRENDERER, and VALUEMAPRENDERER. Your database can have field names in lower case, but you should still reference them using all upper case letters.