ArcIMS administration checklist

A well-tuned ArcIMS site performs well, is stable, and is secure. In some cases, you can change settings in property and configuration files. In other cases, you must configure your site to take the most advantage of CPU usage. The following checklist takes you through the settings you should consider and provides resources for determining the optimal configuration. The checklist is divided into two parts:

Properties and settings used for security
Performance considerations

Properties and settings used for security

Checklist items Comments

Restricting geometry.

___ If you haven't already done so, read the Help topic Restricting geometry in responses.

___ Determine if you need to change the default restriction value for Image Services.

When a client makes a GET_FEATURES request to an Image Service, geometry can be restricted in the response. You may want to restrict geometry for security or performance reasons. One place where geometry is restricted by default is when feature queries by made by ArcMap clients. By default, ArcIMS services do not return geometry, and in ArcMap, selected features cannot be saved.

Different levels of restricting geometry are available:

Geometry can be restricted for all requests. If you select this restriction, any operation that requires geometry will fail in all ArcIMS clients.

Geometry can be restricted when the output mode is binary. This is the default, and this prevents users from saving features in ArcMap.

No restrictions, and geometry can be requested by any client.

For more information on restricting geometry, see Restricting geometry in responses.

Setting featurelimits for tabular data.

___ If you haven't already, read the Help topic Strategies for using feature limits.

___ Assess if the upper limit set for Image Services is adequate for your site. The default limit is 2000. If this value is too high or too low, you can modify it in aimsqs.cfg.

___ Determine if you want an upper limit set for Feature Services. By default, no upper limit is set. With Feature Services, the feature data and geometry are bundled together. When you limit feature data, you also limit geometry. If the value is set too low, some features may not draw on the map. You can add an upper limit in aimsfs.cfg.

ArcIMS services, by design, have no limits on the number of features that can be selected or queried. Users can inadvertently or maliciously request unlimited numbers of features. Feature queries do not have scale dependencies. This means that all features for a layer can be requested even if the layer is not displayed on the map for a given scale. Some common ways a user can request many or all records for a layer are:

Request all cities with a population greater than 0.

Send an empty where statement (where="")

Send a statement that is always true (where="1=1").

Selecting all features in a layer.

You can set a global feature limit in the Spatial Server configuration files limiting the number of requested features from all layers in all services. By default, the feature limit is 2000 for queries made to Image Services. No upper limit is set for Feature Services. Higher values can lead to slower performance. More importantly, when many large queries are executed they may block and prevent shorter queries from executing until completion of the excessively long queries. In addition, large responses can hang a client viewer.

You can also limit the number of features that can be requested on a per-layer basis for Image and Feature Services.

More information on feature limits is available in the Help topic Strategies for using feature limits,

Setting featurelimits for the number of features displayed in an image.

___ If you haven't already, read the Help topic Strategies for using feature limits.

___ Do you plan to display dynamic layers? Your application should disallow displaying dynamic layers at inappropriate scales. However, to protect your site, you may want to include an upper limit for displayed features.

___ Determine an appropriate upper limit. If you expect your largest layer to include 5000 features at its fullest extent, then you would want to set the feature limit greater than 5,000.

You can limit the number of features drawn on a map when using an Image Service. This setting affects all layers in all Image Services, including dynamic layers. Therefore, the value should be larger than the maximum number of features you would expect to be drawn in your largest layer.

Setting an upper limit should only be necessary if for some reason you have many features in a layer and cannot set scale dependencies. Ideally, each layer in a map configuration file should be displayed only at the appropriate scale. However, to prevent users from requesting large amounts of data from dynamic layers, setting a limit may be appropriate depending on the size of your data sets. If no feature limits are set, a user may be able to add a layer with thousands of features.

Setting Spatial Server restrictions when using the Servlet Connector.

___ If you have not already done so, review the Help topic Setting Spatial Server restrictions when using the Servlet Connector.

___ Determine if you want to restrict any output image formats when using the Servlet Connector.

When you use the Servlet Connector, your ArcIMS services are available to anyone who knows the URL for accessing your site. In order to restrict requests that might overload your Spatial Servers, a set of restrictions can be set in the Esrimap_prop property file.

By default, requests can be made for output images in several formats. If you want to restrict a specific format, you can set the restriction in Esrimap_prop. Some output files can get very large, and they may take a long time to generate. You may want to prevent users from requesting these formats.

You can also set or remove restrictions on directories. By default, the location and name of output files cannot be changed through a request. In addition, the directory location of output files is not included in a response - only the URL of the image is given. In most cases, the recommendation is not to change these default values.

For more details on Spatial Server restrictions, see the Help topic Setting Spatial Server restrictions when using the Servlet Connector.

Securing your services when using the Servlet Connector.

___ Determine if you need to restrict any of your services.

___ Follow the instructions in Restricting access to ArcIMS services.

When you use the Servlet Connetor, your services are likely publicly available to any user on the Internet who knows your URL. Anyone using ArcMap or an HTML implementation can make requests to your services. There may be times when you want to restrict access to one or more of your services. As an administrator to an ArcIMS site, you can:

Set usernames and passwords for accessing services.

Define the levels of access to your Metadata Server.

Limit use to designated client machines only (by IP address).

Set an expiration date and time for a user.

Deactivate a specific user.

Restrict use of specific ArcXML elements.

When a service is restricted, users are challenged with a username and password. You can set up either a file-based or jdbc-based access control list that contains the information for restricting services. Information on securing your services is available in Restricting access to ArcIMS services.

Checklist items	Comments
Restricting geometry. ___ If you haven't already done so, read the Help topic Restricting geometry in responses. ___ Determine if you need to change the default restriction value for Image Services.	When a client makes a GET_FEATURES request to an Image Service, geometry can be restricted in the response. You may want to restrict geometry for security or performance reasons. One place where geometry is restricted by default is when feature queries by made by ArcMap clients. By default, ArcIMS services do not return geometry, and in ArcMap, selected features cannot be saved. Different levels of restricting geometry are available: Geometry can be restricted for all requests. If you select this restriction, any operation that requires geometry will fail in all ArcIMS clients. Geometry can be restricted when the output mode is binary. This is the default, and this prevents users from saving features in ArcMap. No restrictions, and geometry can be requested by any client. For more information on restricting geometry, see Restricting geometry in responses.
Setting featurelimits for tabular data. ___ If you haven't already, read the Help topic Strategies for using feature limits. ___ Assess if the upper limit set for Image Services is adequate for your site. The default limit is 2000. If this value is too high or too low, you can modify it in aimsqs.cfg. ___ Determine if you want an upper limit set for Feature Services. By default, no upper limit is set. With Feature Services, the feature data and geometry are bundled together. When you limit feature data, you also limit geometry. If the value is set too low, some features may not draw on the map. You can add an upper limit in aimsfs.cfg.	ArcIMS services, by design, have no limits on the number of features that can be selected or queried. Users can inadvertently or maliciously request unlimited numbers of features. Feature queries do not have scale dependencies. This means that all features for a layer can be requested even if the layer is not displayed on the map for a given scale. Some common ways a user can request many or all records for a layer are: Request all cities with a population greater than 0. Send an empty where statement (where="") Send a statement that is always true (where="1=1"). Selecting all features in a layer. You can set a global feature limit in the Spatial Server configuration files limiting the number of requested features from all layers in all services. By default, the feature limit is 2000 for queries made to Image Services. No upper limit is set for Feature Services. Higher values can lead to slower performance. More importantly, when many large queries are executed they may block and prevent shorter queries from executing until completion of the excessively long queries. In addition, large responses can hang a client viewer. You can also limit the number of features that can be requested on a per-layer basis for Image and Feature Services. More information on feature limits is available in the Help topic Strategies for using feature limits,
Setting featurelimits for the number of features displayed in an image. ___ If you haven't already, read the Help topic Strategies for using feature limits. ___ Do you plan to display dynamic layers? Your application should disallow displaying dynamic layers at inappropriate scales. However, to protect your site, you may want to include an upper limit for displayed features. ___ Determine an appropriate upper limit. If you expect your largest layer to include 5000 features at its fullest extent, then you would want to set the feature limit greater than 5,000.	You can limit the number of features drawn on a map when using an Image Service. This setting affects all layers in all Image Services, including dynamic layers. Therefore, the value should be larger than the maximum number of features you would expect to be drawn in your largest layer. Setting an upper limit should only be necessary if for some reason you have many features in a layer and cannot set scale dependencies. Ideally, each layer in a map configuration file should be displayed only at the appropriate scale. However, to prevent users from requesting large amounts of data from dynamic layers, setting a limit may be appropriate depending on the size of your data sets. If no feature limits are set, a user may be able to add a layer with thousands of features.
Setting Spatial Server restrictions when using the Servlet Connector. ___ If you have not already done so, review the Help topic Setting Spatial Server restrictions when using the Servlet Connector. ___ Determine if you want to restrict any output image formats when using the Servlet Connector.	When you use the Servlet Connector, your ArcIMS services are available to anyone who knows the URL for accessing your site. In order to restrict requests that might overload your Spatial Servers, a set of restrictions can be set in the Esrimap_prop property file. By default, requests can be made for output images in several formats. If you want to restrict a specific format, you can set the restriction in Esrimap_prop. Some output files can get very large, and they may take a long time to generate. You may want to prevent users from requesting these formats. You can also set or remove restrictions on directories. By default, the location and name of output files cannot be changed through a request. In addition, the directory location of output files is not included in a response - only the URL of the image is given. In most cases, the recommendation is not to change these default values. For more details on Spatial Server restrictions, see the Help topic Setting Spatial Server restrictions when using the Servlet Connector.
Securing your services when using the Servlet Connector. ___ Determine if you need to restrict any of your services. ___ Follow the instructions in Restricting access to ArcIMS services.	When you use the Servlet Connetor, your services are likely publicly available to any user on the Internet who knows your URL. Anyone using ArcMap or an HTML implementation can make requests to your services. There may be times when you want to restrict access to one or more of your services. As an administrator to an ArcIMS site, you can: Set usernames and passwords for accessing services. Define the levels of access to your Metadata Server. Limit use to designated client machines only (by IP address). Set an expiration date and time for a user. Deactivate a specific user. Restrict use of specific ArcXML elements. When a service is restricted, users are challenged with a username and password. You can set up either a file-based or jdbc-based access control list that contains the information for restricting services. Information on securing your services is available in Restricting access to ArcIMS services.

Performance considerations

Checklist items Comments

Understanding load factors.

___ Review Understanding load factors.
Every ArcIMS site has different resources, infrastructure, data, and users. What works well for one site may not work as well for another. In order to have a well-performing site, you need to develop the optimal configuration for your organization. System design strategies are beyond this scope of this checklist. However, you should understanding some basic concepts such as throughput, peak hour usage, and response time to the user. If you want to learn more about system design strategies, a good place to start is the Systems Integration Services Web site.

Average image size.

___ What is the average image output size for each service?

___ Experiment with other different formats for each service. Is there a major difference in image size without compromising the quality you need?

___ Check the Spatial Server log files to check the output times. For the location of these log files, see Log file locations and names.

___ Change the maximum image output size allowed, but only if your users really need larger maps. For more information, see Publishing an ArcIMS service. If images take too long to generate, you may need to raise the amount of time allowed for the Application Server timeout. For more information, see Setting timeouts.
___ Determine whether changing the JPEG quality or PNG compression values helps or hinders performance. For more information and benchmark values, see Changing image output parameters.
The size of the image directly impacts the amount of time it takes for the Spatial Server to generate the image and write it to disk.
You can check how long it takes for the Spatial Server to generate an image by looking at the log files. In the log example below, the output time is .04 seconds. The total request time is .23 seconds. Therefore, the output time is almost 20 percent of the total request time.

[time stamp] OUTPUT TIME: 0.046000s
[time stamp] Total Request Time: 0.235000s

The size of the image impacts performance. In the following table, the requested image height and width, output size, and output time are given. This benchmark was based on PNG8 images. The sizes and times are relative but do give you an idea of the impact output size versus output time.

Height and width (pixels) Image size (kb) Output time (sec)

200 x 150 7 .015

400 x 300 19 .047

800 x 600 45 .094

1024 x 1024 64 .172

2000 x 1500 137 .406

4000 x 3000 684 1.92

The default maximum size for an image is approximately 1024 x 1024 pixels. You can change the maximum size in Administrator. Be cautious about raising the limit without considering the performance implications.

You have some control over the image size. Depending on your data, one format will produce a smaller image than other formats. If your map contains only vector data, GIF or PNG8 format may be the best choice. If your map contains imagery, JPEG or PNG24 may be the best choice. Note that JPEG does not support transparency. Therefore, if you plan to merge images from multiple sources, you should not use JPEG. Transparency is also not supported for PNG24 format in Internet Explorer browsers.

If you are using JPEG format, you have some control over the quality. The JPEG quality is set at 85%. You can increase the quality, but the image will be larger and take longer to generate. You can also compress PNG images. While the output may be smaller, compression takes longer to process.

Restricting image output formats.

___ Restrict image output formats, such as PNG24, BMP, and TIFF. Note that these restrictions are only for clients that use the Servlet Connector such as the HTML Viewer or ArcMap. For more information, see spatialServer.ForbiddenImageTypes in Setting Spatial Server restrictions when using the Servlet Connector

When using the Servlet Connector, you can limit which image formats users can request. Common clients that use the Servlet Connector are ArcMap and HTML implementations such as the HTML Viewer.

If ArcMap users are accessing your ArcIMS site, the generated images are in PNG24 format by default. If you feel this format is slowing the overall performance of your site, you can restrict this format.

Zip file size.

___ What is the average zip file size?

___ Determine whether you want to set an upper limit to the zip file size. For more information, see Changing the maximum output file size for data extraction.
If you are using the Extract Server, users will be downloading zip files over the Internet. As with images, you should understand how large the zip files are, and how long it takes to download the file.
If you are concerned about the potential output size of zip files, you can limit the zip file size in the Extract Server configuration file. This improves performance of your site by limiting network traffic.

Network bandwidth.

___ What bandwidth do you expect for the majority of your users?

___ Is the download time you expect for your image and zip files satisfactory to your users?
The network bandwidth determines how quickly your users will get results once the Spatial Server is done processing the request. Users who dial in a modem will wait much longer than users on a T1 line.
After the Spatial Server has generated an image or zip file, the client must retrieve it. The following table shows the number of seconds it takes to transfer a file based on network bandwidth.

Image transfer time (sec) based on average image size

Bandwidth 30 kb 50 kb 100 kb 400 kb

56 Kbps Modem 5.4 8.9 17.9 71.4

1.54 Mbps T-1 0.2 0.3 0.5 2.6

45 Mbps T-3 <0.1 <0.1 <0.1 0.1

Managing Spatial Server recycling.

___ If you are unfamiliar with the terms Spatial Server and Virtual Server, you can learn more in Overview of Spatial Servers, Virtual Servers, and ArcIMS services.
___ If you plan to recycle another Virtual Server, you must set some properties in AppServer.properties. Follow the instructions in Managing Spatial Server recycling.

___ If you recycle another Virtual Server such as an Image Virtual Server, you should have at least two Spatial Servers associated with it. More information on adding and associating Spatial Servers to Virtual Servers is covered in Managing ArcIMS Virtual Servers using Administrator and Managing ArcIMS Virtual Servers using Service Administrator.

___ For all Virtual Server types, how long does it take to add all the services to a Spatial Server? In other words, if you had to restart your site for some reason, how long does it take for all the services to load? This is the length of time a Spatial Server will be unavailable for requests during recycling.

___ How often is recycling occurring for each Virtual Server type? At what time? Is recycling taking place during a peak hour for your site? If yes, you should change the time of day when the server is recycled. You can change this frequency in Administrator or Site Administrator.

Spatial Server recycling is the automated shutdown and restart of an ArcIMS Spatial Server. When a Spatial Server is recycled, resources are reclaimed resulting in better performance. Server recycling is controlled through the Virtual Server. By default, no servers are set to be recyclable. If you have a high volume site, recycling may help clean up resources. While you do have the option to recycle these servers, most ArcIMS sites do not employ this option.

During recycling, one Spatial Server is recycled at a time, and the Spatial Server is unavailable while services are reloaded. Other Spatial Servers associated with the Virtual Server can still process requests. Therefore, you should have at least two Spatial Servers associated with a Virtual Server.
Note that when an Image Virtual Server recycles, the other Virtual Servers (Feature, Query, Geocode, and Metadata) are also recycled. This happens since the entire Spatial Server is recycled each time. If you have separated Virtual Server types onto different Spatial Servers, you can recycle each Virtual Server separately.
For more information on recycling, see Managing Spatial Server recycling.

Setting the load method for ArcSDE raster catalogs.

___ If you are using a raster catalog, review Setting connection parameters for ArcSDE.
By default, all data in a raster catalog is preloaded when a service is started. This means the entire raster catalog is loaded in memory. If you have a very large raster catalog with thousands of rows, it may not be practical to preload the entire catalog. In this situation, you can change a setting so the raster catalog is not loaded into memory, and raster rows are loaded on demand when the service is viewed. This method should only be employed if you set scale dependent visibility for layers referencing large raster catalogs. If the raster catalog layer is viewed at full extent, performance will be slow, and the request may time out.

Setting Tasker cleanup.

___ If you haven't already, review the Help topic Removing output files using ArcIMS Tasker.

___ Determine if the default value of deleting files every 20 minutes is appropriate for each of your services. You can set this value in Administrator or Site Administrator. For more information, see Publishing an ArcIMS service.

___ Include files and directories you want deleted on a regular schedule in Tasks.xml. For example, if you find your Spatial Server log file directories becoming large, you can delete these files on a specified schedule.

As clients make requests, many image and zip files are generated in the ArcIMS Output directory. ArcIMS Tasker keeps track of these output files and deletes them on an interval you specify. Removing output files on a regular basis is important so that your machines do not run out of disk space.
Information about managing output files is covered in the Help topic Removing output files using ArcIMS Tasker.

Adjusting timeouts.

___ If you haven't already, review the Help topic Setting timeouts.

___ If requests are timing out on a regular basis, you may need to increase the timeout value. When using the Internet, the default of 60 seconds is a long time. Many users will give up if a request takes this long. If you find you need to raise this limit because one or more services is responding slowly on a regular basis, you should review the Optimizing ArcIMS services checklist to make your service as efficient as possible. Conversely, if your requests process quickly, you may want to lower the default value so users get feedback more quickly when a request does time out.

___ How long does it take to start each service? If one or more services takes longer to start than the extendedTimeout value, make adjustments accordingly.

Timeouts are an important aspect of server products. Timeouts limit the amount of processing time for requests and limit the amount of time a request stays in a queue. This is important for performance. It also keeps your site running if inappropriate requests are made.

The ArcIMS Application Server has several timeouts. The two timeouts you should be aware of are timeout and extendedTimeout. The timeout value is the amount of time allowed to process a request. The extendedTimeout value is the amount of time allowed to start a service. For more details on these two timeouts plus an overview of other available timeouts, see the Help topic Setting timeouts.

Search code: @checklist_admin