Decoding imagery requires CPU processing. Express Server can reduce CPU requirements by saving raw pixels in the disk cache. This can improve performance significantly for active sites. However, this comes at the expense of increased disk usage. Express Server offers three distinct strategies for caching pixels, each represented by a distinct cache. Each of these caches lives on disk and its size, location and pruning interval are all determined by the Disk Cache settings.
In response to requests, Express Server may cache certain data to disk, including image thumbnails, frequently requested image extractions, and raw pixels. You can specify the folder in which Express Server stores the temporary files, the amount of disk space Express Server can use for the disk cache and the number of minutes between automatic purges of the disk cache.
To specify the disk cache folder:
By factory default temporary files are stored in <Express Server installation directory>/ImageServer/var/cache/iserv_images/
To set the prune interval:
The default interval is 360 minutes (6 hours).
To set the maximum cache size:
The default maximum cache size is 512 megabytes.
There are three pixel cache options; Image, Index and Warp.
The Image caching strategy involves caching the pixels from images as they are decoded. This strategy may be useful for sites that have many different images to serve and are not using the spatial index or WMS features of Express Server. LizardTech recommends enabling this strategy for non-WMS sites.
The Index caching strategy involves caching the pixels decoded from a spatial index. A spatial index is a special type of Express Server catalog that dynamically combines a collection of spatially related images into a single mosaic. WMS GetMap requests use the spatial index. When this strategy is employed, the pixels from the index are cached, rather than from the individual images that are included in the index. LizardTech recommends enabling this strategy for WMS sites.
The Warp caching strategy involves caching pixels after they have been reprojected or “warped”. This only affects WMS GetMap requests that require reprojection. LizardTech recommends enabling this strategy for WMS sites in which most requests require reprojection.
To specify a pixel cache:
NOTE: The Image, Index and Warp caches can be used in combination with each other, but to reduce the performance costs associated with filling the caches, we recommend that you enable only one pixel caching strategy.
Four settings enable you to fine tune any of the pixel caching strategies to optimize performance. These settings specify the width and height in pixels of each block saved in the cache, the minimum allowable ratio of requested scene pixels to decoded tile pixels, and the maximum image resolution at which caching occurs.
The Width parameter indicates width in pixels of each block saved in the cache. The default value is 200.
The Height parameter indicates the height in pixels of each block saved in the cache. The default value is 200.
The pixel caches sort an image into tiles of fixed width and height. When Express Server receives a request to decode an image (i.e. the getimage or GetMap requests), the pixel cache will decode all the tiles that intersect with the specified scene. In most cases the area of all the tiles will be larger than the area of the requested scene. The result of this is that more pixels will be decoded than are necessary to satisfy the given request, initially hurting the performance of the server. However, because these tiles are then cached, subsequent requests will not have to decode any pixels, improving performance of the server.
The Utility parameter specifies the minimum allowable ratio of scene pixels to tile pixels. If the number of pixels in the requested scene divided by the number of pixels required to decode the intersecting tiles is less than this value, then the tiles will be clipped. The valid range is 0.0 – 1.0.
Some examples:
A utility of 1.0 specifies that no extra pixels will ever be decoded, and only those tiles that fall completely within the bounds of a requested scene will be cached. This setting causes the least initial overhead, but because fewer tiles are cached, performance improvements resulting from the cache will take longer to accrue.
A utility of 0.0 indicates that all intersecting tiles will be decoded, regardless of the size of the requested scene. This is the default value. This may cause some initial performance degradation, but since all tiles are cached, performance will quickly improve.
A utility of .85 specifies that the pixel cache will always make sure that 85% of the pixels it decodes for a particular scene will be used in that scene. If the number of pixels required to fill the intersecting tiles exceeds that percentage, then they will be clipped.
The default and recommended value for the Utility parameter is 0.0.
The Max Mag parameter specifies the maximum image resolution or "magnification" at which caching occurs. All requests for scenes at magnifications higher than this value will not be cached; all requests for scenes at or below this magnification will be cached. Decimal values greater than 0 and less than or equal to 1 are valid.
The default value is 1.0, indicating that decode requests at full resolution (1.0) will be cached, as will all decode requests at lower magnifications (i.e. zoomed out).
Requests at magnifications greater than 1 will not be cached.
To fine tune the pixel cache
In order to enable maximum performance with minimal resource requirements, Express Server employs certain strategies in its image handling. The Image Manager settings allow you to define parameters used in these strategies.
The extraction cache trigger setting specifies the number of times a particular scene may be requested before it is cached to disk. For example, if this value is set to 3 and the extraction list size is 10, then a particular scene will be cached to disk if 3 out of the last 10 extraction requests for that image were for that scene.
The extraction cache trigger is ignored if the extraction list size is 0 or missing.
The default extraction cache trigger value is 2.
The most CPU expensive operations on Express Server are extraction requests. If certain scenes are extracted frequently, then caching them to disk may have a beneficial effect upon performance. Express Server keeps track of requested extraction scenes, and when it notices that one or another scene is requested frequently, it will cache the result to disk for quick access later. The extraction list size specifies the number of extraction requests Express Server monitors for each image.
For example, if the value is 10, then Express Server will keep track of each image's last 10 extractions. If either this or the extraction cache trigger is set to 0 or missing, then Express Server will not monitor scene extractions.
The default extraction list size is 50.
The extraction timeout specifies the maximum number of seconds that an extraction request will wait in queue before it is discarded.
This value is ignored if the maximum concurrent extractions (max current extractions) is 0 or missing. If extraction timeout is missing, or is set to 0, then the pending extraction requests will wait indefinitely.
The default value is 50.
As noted above, the most CPU expensive operations are extractions. These operations occur in response to getimage requests in the Web API, GetMap requests in the WMS API, and ltcsExtract functions in the C API. In these operations, Express Server decodes a portion of the source image and reencodes to an output format such as TIFF or JPEG.
If Express Server is hit with a large number of extraction requests at one time, then server performance may suffer.
The max concurrent extractions property specifies the maximum number of extractions that may be processed concurrently. Extraction requests occurring in excess of this number are placed in queue, and handled on a first-come, first-served basis.
If the max concurrent extractions value is missing or is set to 0, then the number of concurrent extractions is not limited.
The default max concurrent extractions value is 50.
The first time Express Server receives a request for data from a particular item, it loads data about the item into memory for quick access later. Since a given item may be gigabytes in size, it does not load the whole item into memory. Rather, it only loads information which allows it to access the item efficiently in response to subsequent requests. This information is stored in an internal memory cache called the "item cache". The item cache size specifies the maximum number of items held in the item cache.
The default value is 1000.
NOTE: JPEG 2000 source imagery uses a lot of memory. Setting this value lower (150-200) will help ensure that you don't run out of memory when JP2 source images are being used.
Each item contains one or more or images. These images are also cached for quick retrieval, in the image cache. The image cache size specifies the maximum number of images which can be stored in this cache.
The default value is 500.
Express Server uses multiple threads to process image requests more quickly. By default, Express Server creates the maximum number of threads possible equal to the number of cores in the processor of the machine that hosts the Express Server. For example, an eight core processor could run eight threads simultaneously. If you want to limit the processing power used by the Express Server, you can limit the maximum number of threads created.
The default value is -1, which indicates that Express Server creates as many threads as possible for optimum performance.