Show Navigation | Hide Navigation
You are here:
Image and raster data management > Serving raster data > Serving raster data > ArcGIS Image Server extension > Designing an image service definition

Optimization considerations for ArcGIS Image Server

Release 9.3
Last modified February 2, 2010
E-mail This Topic Printable Version Give Us Feedback

Print all topics in : "Designing an image service definition"

Related Topics

The speed at which image service definitions are processed and returned to clients can be affected by a number of factors including the hardware and its configurations, the number of pixels for the source imagery that need to be read, where or how the imagery is stored, the number and types of image service definition processes, the mosaicking methods, the compression of the source imagery, and the compression used for transmission.

Response time

Response time is composed or processing time (X) and transmission time (T).

total response time (TR) = X + T

The processing time is dependent on many factors, including the number of pixels that will be read, how the source imagery is stored (involving format, compression, and hardware), and what processing is required, whereas the transmission time is dependent on the network.

Each (client) connection to ArcGIS Image Server occurs as a separate thread on the computer's processor. Multiple cores do not make a connection faster; however, multiple cores allow more connections than a single core. You can calculate the approximate requests per hour (RPH) using the following formula:
RPH = 3600 * (C/X)
C = number of cores
X = processing time (seconds)

For example, using a typical server configuration of a two-socket, dual core 3.0 GHz machine with 2 GB of RAM; an 800 x 600 pixel request from JPEG compressed, three-band TIFF images; stored on a single SATA disk with a 100 megabits per second LAN; with no processing and using bilinear sampling, you should typically see the following results:

processing time (X) = 0.4 seconds
transmission time (T) = 0.3 seconds
total response time (TR) = 0.7 seconds
requests per hour (RPH) = 3600 * 4 / 0.4 = 36000

If you reduce the number of cores, the response time will not change; however, the number of image service definitions that can be served per hour will be reduced.

Hardware considerations

ArcGIS Image Server is CPU intensive and memory efficient. As mentioned in the earlier section, the server is good at spreading the load and will use multiple processors for multiple requests. Therefore, it is recommended to have a two-socket server. Although ArcGIS Image Server is memory efficient, it is memory intensive because it is moving a large number of pixels. It is recommended that the computer have a faster front-side bus to move the information in the memory as quickly as possible. Although the amount is not critical, it is recommended that the server have 1 GB of RAM with 500 MB per core.

The hard disk on which the source imagery is stored experiences a typical disk load of approximately 15 percent for the duration of a request when using uncompressed imagery. Using compressed imagery reduces this by the compression factor of the imagery. It is faster to move around compressed imagery; however, not all compressions have the same effect on reducing the processing time, since they need to be uncompressed before being processed, mosaicked, then transmitted to the client. The decompression of JPEG images is extremely fast. Other compression methods, such as MrSID or JPEG 2000, require more processing and memory, which can reduce access speed. For MrSID, this is about two to four times, and for JPEG 2000, this is about four to six times.

When storing your data, you need to consider the storage system, of which there are three main types. The direct attached storage (DAS), often with a redundant array of independent disks (RAID), is the optimum hard disk implementation. Generally, data on a DAS is primarily accessed only by the machine to which it is connected. The storage area network (SAN) or network-attached storage (NAS) systems work well; however, a heavy load can be placed on them when using uncompressed imagery and many simultaneous requests. With NAS and SAN, multiple machines have access to where the data is stored. External hard drives that are connected using USB or FireWire are adequate for small workgroups; however, this is not recommended for an enterprise environment.

When storing your image data on an SAN or any device other than the machine where the service provider is installed, there are two steps that need to be followed. Step 1: When creating the image service definition, be sure the location of the source images is defined using a Universal Naming Convention (UNC) path. Step 2: Set the SYSTEM group on the SAN or device containing the source imagery to have read access to the data. The service provider runs under the SYSTEM group account and must have read access to the device where the source imagery resides.

When formatting the disk of the storage device, the block factor often defaults to 4 KB. This is adequate when using compressed imagery; however, when using imagery that is not compressed and is stored as considerably large files, the block factor should be set to 16 KB.

Pixel source

The speed at which an image service definition is processed is also affected by how many pixels are required, the source image format and compression that need to be accessed, the number of bits per pixel, the number of source images that need to be accessed, and the rotation of the source imagery containing the required pixels. On average, the number of pixels read from the source imagery can be one to nine times greater than the number of pixels in the image service definition output.

The administrator of the image service definition can limit the number of pixels that can be returned at one time from an image service definition, which limits the length of time that an image service definition is being processed. This is specified as a limit to the number of pixels in rows and columns. The purpose of this limit is to keep clients from downloading excessively large and processing-intensive requests. Basically, the larger the request size, the longer it takes to process.
Learn about the settings for the client's interface

The access to pixels is also controlled by the format and compression of the source imagery. Generally, compressed formats result in the need to read fewer bits from the storage disk but may require more time for processing. The following are observations for particular formats and compressions:

*A large file is approximately 10000 x 10000 pixels, uncompressed; this is approximately a 100 MB panchromatic (one-band) image or a 300 MB color (three-band) image.

Considerations need to be made when generating the service overviews. By default, the service overviews are created at a factor of three times the source imagery as opposed to two. This conserves more hard drive space, but when making requests of random pixel sizes (at random scales), more pixels on average need to be read, resulting in a speed decrease of approximately 20 percent in comparison to accessing the pixels from service overviews that are created with a factor of two. The service overview factor can be modified in the Service Defaults node of the Image Service Properties dialog box.

Increasing the number of bands or bits per pixel increases the volume of data that needs to be read. For example, 16-bit data, which is basically twice as much as 8-bit data, is approximately 25 percent slower. Additionally, reading pixels from three-band imagery takes 30 percent more time than from one-band imagery.

The number of source images that need to be read for each request affects the processing speed. This is mostly affected by the mosaicking method or the particular processes that may be used by the image service definition. On average, the following is true:

X = X + R * Q
Processing time (X)
Number of rasters (R)
Time to open a raster (Q) in seconds

Q can vary from approximately 0.01 to 0.1 second. Generally, it is faster to use larger files so each request does not need to open many files. It is also recommended that larger files utilize tiled data structures to reduce disk access such as tiled TIFF.

Imagery that is rotated can also slow down the access to the correct pixels. Typically, a request using an image that is rotated 45 degrees would require about double the disk access. There are substantial advantages to using tiled imagery for rotated images. Generally, small images or large tiled imagery have little effect, but large nontiled images that are rotated require more processing time.


ArcGIS Image Server is more than a server that streams out image data, and the processing time to serve the data can be affected by adding image processes. Different processes have different speed effects; therefore, depending on the processes that are added to an image service definition, the processing time may increase.

Generally, when adding radiometric processes to enhance the appearance of the imagery, such as a linear stretch, the processing time may be increased by 5 percent. If you apply a Convolution Filter process, the processing time may increase by 25 percent when using a 3 x 3 kernel or by 50 percent for a 5 x 5 kernel. When using an image fusion process, such as Grayscale, or an image algebra process, such as NDVI, the processing time may increase by 10 percent. Additionally, if you apply a process to the individual rasters versus applying the process to the whole image service definition, the processing time could increase by 5 percent.

When using geometric processes (including reprojection), the processing time can be affected by the complexity of the transformation. ArcGIS Image Server does not transform each pixel; instead, it performs an analysis of the transformations that are required and breaks the requests into small tiles, where the deviation within a tile of a pixel is not to be more than half a pixel in the output. Most simple transformations require few tiles to achieve this accuracy and the amount of tiles is determined automatically. For a process such as orthorectification, the tiling of the request is controlled in the ortho parameters by the anchor spacing, maximum number of tiles, and the digital elevation model (DEM) spacing parameters. The anchor spacing (for example) is the distance measured in output pixels between sampling points. If the anchor spacing is small, the request is split into more tiles, increasing the computations performed and data processing. If the anchor spacing is 100, then for each 100 pixels in the output, one sampling point is measured in the source data. For a screen resolution of 1000 x 800 pixels, this would result in a total of 80 samples. On average, if the anchor spacing is 100 pixels, it adds 10 percent to the total processing time; for 50 pixels, it adds 20 percent; and for 4 pixels it adds 100 percent. Four is the recommended value for higher accuracy, but as you can see, the processing time is slower. The processing times are also dependent on the complexity of the sensor model being used.

Learn about the orthorectification parameters.

The sampling method used in the geometric transformation also affects the total processing time. A nearest neighbor sampling method tends to be 10 percent faster than the bilinear interpolation, whereas cubic convolution tends to be 20 percent slower. This is because for these transformations, each has to consider a different number of pixels surrounding each pixel, with cubic convolution factoring in the most and nearest neighbor the fewest.

General settings

When pixels in imagery are to be interpreted as transparent, the service provider has to perform a lot more work to create the output image. Using transparency is an optional setting that is not always applied to an image service definition. Normally, images are clipped by their footprint, which minimizes the number of pixels that need to be read from each image. When using transparency, every image needs to be read and every pixel needs to be examined for the transparency to be applied correctly. This can increase the processing time by up to 1,000 percent if there are many overlapping images. Therefore, it is recommended that footprints be modified wherever possible, such as around the edges of images, to minimize the use of transparency.

Learn about editing the shape of the footprint.

The mosaic method, which can be set by the administrator creating the image service definition and also by the client, can affect the processing time. The Closest to Center and Viewpoint mosaic methods often only require the pixels from one source image to be read. The By Attribute and Seamline mosaic methods often increase the number of source images that need to be read. When using the Seamline mosaic method, feathering can be applied. Feathering refers to the blending of the pixels along the seamline. The width of the feathering region can be defined in pixels or meters and can be either inside or around the seamline. Basically, the greater the feathering region, the greater the effect on processing time, which may vary from 10 to 100 percent.

The area of pixels to read from the source imagery is defined by the footprint or the seamline. Normally the footprints have only four vertices, but they can have more, and the seamlines can have a large number of vertices. The process time can be affected if there are too many vertices; therefore, when optimizing an image service definition, it may be useful to simplify these polygon shapes.

The type and amount of compression applied to the image data before it's sent to the client can be defined by the administrator of the image service definition and altered by the clients. If the image is uncompressed, the total response time is affected primarily by a longer transmission time; however, if it is compressed, the total response time is affected primarily by a longer processing time. On average, a JPEG compression can add 5 percent processing time. LZ77 is similar, and JPEG 2000 takes a little longer. The amount of processing time to compress the transmitted image is generally negligible because the transmission time is greatly reduced, thereby getting to the clients quickly. Of course, the transmission time is also affected by network bandwidth, which can't always be optimized but should be considered.

Other considerations

The volume of source image data and the number of image service definitions have no effect on the speed of serving image service definitions. The number of image service definitions may slightly increase the memory usage, but this is minor.

It is important to take time to plan and prototype your image service definitions. As when building any large database, you need to consider several factors of the data structure. When storing source imagery, it is recommended that it be organized into folders containing no more than 500 images. Make sure the storage disks are not filled beyond 95 percent. Also, dedicate storage disks to ArcGIS Image Server. When the image service definitions are published, ArcGIS Image Server only reads from the disk; therefore, this does not add to disk fragmentation. However, if there is another application that might be writing to the disk, fragmentation of that disk could occur, which affects long-term performance. Writing and reading from the same disk can also decrease performance. A substantial decrease in the performance of a server can be noticed on some systems when users copy large volumes of data to or from the disks. It is advantageous to utilize dedicated disk storage for static image data.

ArcGIS Image Server is an application server, and it is recommended that such servers use a dedicated machine. This ensures that the software has full control of server resources and that memory and resources are not fragmented with other applications. It is often better to have ArcGIS Image Server running on a separate, small server than attempting to combine many applications on the same server. ArcGIS Server and ArcGIS Image Server run well together on a single server, but better performance will be seen by both applications if they are on separate servers.

Having ArcGIS Server utilize ArcGIS Image Server as a source for raster imagery has a number of advantages. When ArcGIS Server requires an image, ArcGIS Image Server provides the image already processed and ArcGIS Server only needs to merge the imagery with other data prior to transmission. Data access and processing load on ArcGIS Server are therefore reduced, and performance increases. ArcGIS Image Server performs the image access and processing, which it is highly optimized to do. Having both applications on the same server means that a request needs to share the same resources. If there are only a few simultaneous requests, there will not be a noticeable difference, but as the number of simultaneous requests increases, the competition for resources increases.

Additionally, be aware of other applications that may be running such as a virus-scanning utility. Other applications can affect the speed on a server, which affects the response time of ArcGIS Image Server.

Please visit the Feedback page to comment or give suggestions on ArcGIS Desktop Help.
Copyright © Environmental Systems Research Institute, Inc.