So I was just playing around with a simple ArcGIS Server app, seeing what I
could do to reduce the amount of data sent to the client and at the same time
speed things up a little. I took a look at the PreferredTileHeight
and Width properties of the Map control. By default, these values are set to
zero, which means that each tile will be the size of the entire map control.
But, if you have a pretty large map, a small pan can result in a lot of data
being sent back to the client.
[I should note at this point that for this use case, we cannot build a tile
cache - the data is too dynamic and the cache cooking process is too slow - maybe at 9.3 when the cache can be cooked dynamically.]
Supposing you have an 600 x 600 map canvas, and since you’ve got imagery,
it’s set to 24bit PNG. In my testing, this results in a ~700kb image (example here) on average.
So – if the user just pans down and right a little, ArcGIS Server will be
creating and sending three 700kb images for a total of 2.1 Mb of data being
transferred. Not bad on a LAN, but a few users like this can overwhelm at T1
pretty quickly.
My idea was to set the PreferredTileHeight and PreferredTileWidth to some
smaller value – say 200 x 200. In that case, a small pan would result in (at
most) 7, smaller tiles (example) being sent across, and since these averaged 100kb each,
it would be 1/3rd the data sent across the wire as compared to the 600 x 600
tiles. The end result was a much smoother panning experience for the map service
with the imagery (occasionally there were “tile holes” though – not sure
why).
Where things got interesting is when I switched to a different map service
which was just vectors. More specifically this service has feature labels. It seems that the rendering engine does not know that it’s sending the data
as a block of tiles – thus it renders a label for each feature in each tile, resulting in repeated labels across the image. This makes sense, but ends up looking a little weird…
TileCache gets around this by rendering much larger “super tiles” which are then
cut up into the smaller tiles – and this avoids the multiple-labelling
issue. Anyhow – if you are thinking about using a non-zero value for PreferredTileHeight / Width, watch out for this.
