Performance tips for Web applications

Performance of a Web application involves both the speed at which the application responds to users and the number of users that an application can accommodate. When you think about improving the performance of your ArcGIS Server Web applications, the first thing that may come to mind is adding or upgrading hardware. However, there may be other things you can adjust in your application, your map, or your server settings that will improve the performance of your Web applications.

Design your map for performance

Designing maps for the Web is very different from designing paper maps, or even maps that you commonly work with in desktop applications such as ArcMap. If you have a map document that you commonly use in ArcMap, you may want to save a copy instead of publishing the map directly to ArcGIS Server. Using the copy, you can make some optimizations specifically for Web viewing.

What's so different about maps that you'll view on the Web? To get the best performance of your map over the Web, it's recommended that you use the Map Service Publishing Toolbar in ArcMap to examine your map document. Resolve all the Errors and as many of the Warnings as you can, then publish the map using the toolbar. This bases your service on a map service definition (.msd, or MSD) file, which is the way to publish your service for the fastest drawing available.

Regardless of whether your map service is MSD-based, you should still consider caching it for performance. Caching a map means that you create and store a set of prerendered map images that can very quickly be used by the application instead of waiting for the map to draw each time. If caching the map, you'll need to design the map to look good at all the scales at which it will be cached. See Planning a map cache for ideas on how to do this.

Cache your map services

Cached map services distribute predrawn map tiles instead of drawing map images on the fly. Cached services not only improve the display speed of your map but also greatly increase the number of users your server can accommodate. For a public-facing Web application, you should always cache the basemap service and attempt to cache all the operational overlay services that are feasible to cache.

Evaluate the image format that your map cache is built with

The image format that you choose affects the performance, appearance, and size on disk of your cache. PNG 8 works well for many MXD-based overlay services, while PNG 32 is a better choice for MSD-based overlay services. For basemaps, JPEG is often the best choice, especially if the map has a lot of color variation. See Available map cache properties to learn more about each image format.

Avoid caching map services in PNG 24

Internet Explorer 6 has limitations in its ability to display transparency for PNG 24 images. The Web ADF includes code that works around this limitation, but there is a performance penalty incurred when this scenario is encountered. Avoid this scenario by doing the following:

• Caching your map services in PNG 8, PNG 32, or JPEG format if Internet Explorer 6 must be used.
• Using a browser other than Internet Explorer 6 to view overlaid map services cached in PNG 24 format.

Use ArcGIS Server Internet connections when possible

Connect to your server using ArcGIS Server Internet connections to make more efficient use of server context requests. ArcGIS Server Local connections should be used only when the application requires changing the state of the service, which includes editing data with the Web ADF.

Ensure that the Overview Map control uses static mode

If your overview map appears to be slowing performance by constantly changing its scale and extent, open your Web application in Visual Studio and ensure that the OverviewMap control's StaticMode property is set to True. This prohibits the OverviewMap image from changing when the Map extent changes.

Configure the TOC control to optimize performance

The TOC control has several options that allow you to reduce the amount of information requested from the server.

• TOCType: The default setting of SwatchList will generate a TOC listing both the layer names and the symbology within each layer. Changing this setting to LayerList will reduce the amount of information requested from the server by only displaying the layer names and not the symbology.
• RenderOnDemand: When a TOC is configured to display symbology, setting this property to True will delay the requesting of swatch information until a layer is expanded. This will help improve the initial startup time of the application.
• ExpandDepth: Use a value of 0 or 1 to minimize the number of nested layers visible when the TOC is displayed at initial application startup.

Consider setting the Visible property on some of your MapResourceItems to False. This will result in the application opening faster, but be aware that the Web page user will need to turn on the layers manually.

Remove unnecessary Web controls

The default Web Mapping Application that you see in Manager or your IDE includes Web controls such as the TableOfContents, OverviewMap, and Scalebar. As you interact with your application, these controls request new images and updated status information. Eliminating controls from the application that are rarely used will help improve the application performance and scalability of the system.

Configure your Web services to avoid per-request impersonation

When preparing your deployment environment, you need to make changes to avoid overworking the Local Security Authority Subsystem Service (lsass.exe).

When someone makes a request from one of your Web services, the Web server must authenticate itself with the server object manager (SOM). The Web server accomplishes this by impersonating the ArcGIS Web Services account, which was added to the AGSADMIN group when you ran the postinstallation. This impersonation doesn't cost much under light loads, but under heavy loads, the lsass.exe process can become overworked, causing a noticeable lag in performance. Heavy loads are considered 25 or more requests per second.

You can avoid this per-request impersonation by configuring your Web services to run in an application pool that runs under the identity of the ArcGIS Web Services account. This lightens the load on the lsass.exe process and ultimately allows your services to run faster.

These ESRI Knowledge Base articles give additional background on the problem and describe how to make the adjustments to your configuration:

• 32620 (Windows Server 2003)
• 32622 (Windows XP)

Use good coding practices

If you are customizing the Web mapping application in Microsoft Visual Studio or creating your own application from scratch, use the coding best practices in Optimizing performance in Web ADF applications in the Developer Help.

Avoid unnecessarily large queries

ArcGIS Server map services limit the number of records that can be returned by a query to 1,000 by default. Keep this value or lower it for best performance with queries. You can change the number of allowable result records by editing the MaxRecordCount property in the map service configuration file.

Use caution if you raise the default value. Queries that return more than 2,000 records require the software to create scratch workspaces in your system TEMP directory to manage the result records. This can cause performance to degrade.

Use local paths

Using local paths to source maps and data tends to give better performance than using network or Universal Naming Convention (UNC) paths. If you use local paths and have more than one server object container (SOC) machine in your deployment, you'll need to duplicate the data on each machine using identical paths.

For help deciding whether to use a central ArcSDE server or local file geodatabases, see Data storage considerations for ArcGIS Server.