Optimization considerations for ArcGIS Image Server

Legacy:

ArcGIS 10 is the last release of the stand-alone ArcGIS Image Server product. The image service definition (.ISDef) has been replaced by an improved geodatabase data model—the mosaic dataset—which can be published as an image service using the ArcGIS Server Image extension.

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

Response time

Response time is composed of two things: the process time (X) and the transmission time (T).

total response time, TR = X + T

The process 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 will not make a connection faster; however, multiple cores will allow more connections than a single core. You can calculate the approximate requests per hour (RPH) using this formula:

RPH = 3,600 * (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 mbps 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) = 3,600 * 4 / 0.4 = 36,000

If you reduce the number of cores, the response time will not change; however, the number of image services 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 very good at spreading the load and will use multiple processors for multiple requests. Therefore, it is recommended that you have a two-socket server. Although ArcGIS Image Server is memory efficient, it is memory intensive because it is moving a lot 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 will experience a typical disk load of approximately 15 percent for the duration of a request when using uncompressed imagery. Using compressed imagery will reduce 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 decompressed before being processed, mosaicked, and 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 will be about two to four times, and for JPEG 2000, this will be about four to six times.

When storing your data, you need to consider the storage system, of which there are three main types. 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 on which it is connected. The storage area network (SAN) and network-attached storage (NAS) systems work well; however, a heavy load can be placed on them when using decompressed imagery and many simultaneous requests. With a NAS and SAN, multiple machines have access to where the data is stored. External hard drives that are connected using USB or FireWire are okay to use for small workgroups; however, it is not recommended for an enterprise environment.

When storing your image data on a SAN, or any other device besides the machine where the service provider is installed, there are two steps that need to be followed. Step one: When creating the image service, be sure the location of the source images is defined using a Universal Naming Convention (UNC) path. Step two: Set the SYSTEM group on the SAN or device containing the source imagery to have read access to the data. This is because 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 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 output.

The administrator of the image service can limit the number of pixels that can be returned at a time from an image service, which will limit the length of time that an image service 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 will take to process.

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 require more time for processing. Observations for particular formats and compressions are as follows:

• Tiled TIFF with JPEG compression—This is the recommended storage format for source imagery because it performs the fastest in ArcGIS Image Server. All percentage estimates will be compared to this.
• TIFF raw—On average, small files are no different than TIFF with JPEG compression; however, large* files will be 20 percent slower.
• MrSID—Approximately 100 percent slower.
• JPEG 2000—Approximately 200 percent slower.
• IMG with RRD—Approximately 50 percent slower.
• JPEG—On average, small files are no different than TIFF with JPEG compression; however, large* files will be 400 percent slower because there is no internal tiling.

*A large file is approximately 10000 x 10000 pixels uncompressed. This is approximately a 100 MB panchromatic (1-band) image or a 300 MB color (3-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 will increase the volume of data that needs to be read. For example, 16-bit data—which is basically twice as much data as 8-bit data—will be approximately 25 percent slower. Additionally, reading pixels from three-band imagery will take 30 percent more time than from one-band imagery.

The number of source images that need to be read for each request will affect the processing speed. This is mostly affected by the mosaicking method or the particular processes that may be used by the image service. On average, the following holds 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 seconds. 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 access to the correct pixels. Typically, a request using an image that is rotated by 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 will have little effect, but large nontiled images that are rotated will require more processing time.

Processing

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 effects on speed, therefore, depending on the processes that are added to an image service, 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 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, 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 more than half a pixel in the output. Most simple transformations require very few tiles to achieve this accuracy. 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 will be measured in the source data. For a screen resolution of 1000 x 800 pixels, this would result in a total of 8,000 samples. On average, if the anchor spacing is 100 pixels, it will add 10 percent to the total processing time; for 50 pixels, it will add 20 percent; and for 4 pixels, it will add 100 percent. Four is the recommended value for higher accuracy, but as you can see, the processing time will be slower. The processing times are also dependent on the complexity of the sensor model being used.

The sampling method used in the geometric transformation will also affect the total processing time. A nearest neighbor sampling method tends to be 10 percent faster than 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. 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.

The mosaic method, which can be set by the administrator creating the image service but also by the client, can affect the processing time. Closest to Center and Viewpoint mosaic methods often only require the pixels from one source image to be read. By Attribute and Seamline mosaic methods often increase the number of source images that need to be read. When applying 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 in 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 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, 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 and can be altered by the clients. If the image is uncompressed, the total response time will be 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, LZ77 is similar, and JPEG 2000 will take a little longer. The amount of processing time to compress the transmitted image is generally negligible because the transmission time will be greatly reduced, thereby getting images to clients quickly. Of course, the transmission time will also be 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 services has no effect on the speed of serving image services. The number of image services may slightly increase the memory usage, but this is very minor.

It is important to take time to plan and prototype your image services. As when building any large database, you need to consider several factors of the data structure. When storing source imagery, it is recommend 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 image services are published, ArcGIS Image Server only reads from the disk, therefore, it 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 that will affect the long-term performance. Writing and reading from the same disk can also decrease performance. A substantial decrease in 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 experienced with 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 is 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 will increase.

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