topic Re: Reasons for poor performance of Image Server 1Caching in 10? in ArcGIS Image Server Questions

Reasons for poor performance of Image Server 1Caching in 10?

PeterTimmers — Tue, 28 Sep 2010 00:40:18 GMT

We've got a couple of base layers we create using the Google Cache schema.

One is a topo cache and the performance has been outstanding in 10. Compact cache, data all sitting in SDE and using a msd.

The other is a aerial cache using a image service (derived referenced mosaic dataset with a little street labelling) from same machine and the performance has been comparitively bad.

ie. Ran over weekend using 250K map sheets down to 1:1000 and was able to do 4 sheets in topo and 1% of one map sheet with aerial.

I'm looking at doing 141 mapsheets (~1.737??10^6 km^2) so imagery is not going to cut it. I'm not going to do that whole area down to 1:1000 but probably at least 30 mapsheets all the way down.

Has anyone noticed poor speed with image services in 10? Our overviews and source data are sitting on another machine but the two machines are on 3Gb connection right next to each other. I have notice some slow speeds with uri addresses in 10 compared to 9.3.1 in catalog.

Is it correct the image services aren't allowed in msds... I thought they were going to be allowed in 10?

Re: Reasons for poor performance of Image Server 1Caching in 10?

larryzhang — Tue, 05 Oct 2010 10:50:23 GMT

Firstly, please read advices from ESRI Image Team at the caching image data of Mosaic Dataset (http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html?TopicName=What_is_raster_data%3f#/About_serving_raster_and_image_data/009t000000p0000000/ )

Secondly, from my practices with 10 (mosaic datasets), if correctly setting up some of parameters for 'Define Overviews' , saying 6 or 9 levels, the results are fast enough in applications. Of course, this mosaic dataset with 6-or 9-level overviews should not be very often updated, if it is very large mosaic datasets (saying, LZW-compressed raw images for a mosaic dataset are larger than 1 TB).

Honestly, it is still not as fast as cached images from combined MXD. Obviously, I need more practices on this to get familiar with this product.

Re: Reasons for poor performance of Image Server 1Caching in 10?

PeterTimmers — Tue, 05 Oct 2010 22:24:20 GMT

We've got the possiblity of lots of people hitting our application so I need a scalable map service.

We use some image services in our application for less important layers.

I'm using the image service in an mxd.

Re: Reasons for poor performance of Image Server 1Caching in 10?

larryzhang — Wed, 06 Oct 2010 04:45:02 GMT

We have only tried one very-large Mosaic Dataset in applications (the original imagery size is 2 TB, but using LZW-based storage strategy is 1 TB, at local SAN).

The picture for this try of this latest mosaic dataset in our applications is as follows:

(1). One web application (for safe, minimum 100 users hit daily)
(2). 200 workstations (about 100 engineers/geologists/cartographers use daily)

For web applications, the background is the cached historical images; Onto the top of this background cached imagery, the latest mosaic dataset is programmatically added with scale-dependency.

Inversely, we only use image service(s) of Mosaic Datasets in our applications for most important and latest layers. The cached images are only used for background, and sometimes, also for historical comparision.

Performance comments:

(1). For web applications, it looks OK, at least acceptable; in other word, with this strategy, it is comparable to the cached images;

(2). For workstations, it looks fine, much faster than raster catalog from SDE, but little slower than old image services from standalone ArcGIS Image Server 9.3/10, which are created within image service editor;

PS.,

(1). This background cached images were derived from several-level historical imagery, which is combined with 2000-m image, 200-m image, 15-m images of Landsat 7, 2.5-m images of SPOT 5, 1-m images of IKONOS;

(2). The mosaic dataset (of 0.5-m GeoEye) has two versions of image service: without overviews (updated weekly, even daily sometimes), and with 6-level overviews (rarely updated);

(3). The image service(s), especially, without overview, are programmatically called with scale-dependency into the web applications as separate layer(s).