Mapfile Tuning

[Ed McNierney]

Frank -

Thanks; is that the case for all projection definitions advertised in a
WMS service, even if a specific request doesn't use them?  I was under
the impression that there was no file access penalty for just
advertising a lot of projections.

Outside of WMS advertisements, most PROJECTION blocks aren't optional in
a map file, of course.  It was a while ago and I didn't do very formal
testing, but my recollection is that the EPSG PROJECTION lookup phase
for loading a relatively simple layer definition was indeed the most
expensive part of that layer load, even though it didn't take very long.

It's important for all of us to think through what will happen on a
given map request.  Layers in a map file that are included in a given
request (i.e. they're turned on, so they might be needed) will trigger
some processing and file I/O even if there ends up being nothing to
draw.  For example, if I have a simple raster layer with a TILEINDEX,
MapServer will need to (a) open the TILEINDEX shapefile, (b) possibly
deal with reprojecting the bounding box, (c) check to see if the
shapefile bounding box intersects with the request, (d) if so, check to
see if any tiles intersect with the request, and then (e) possibly draw
nothing at all.  This is after the map file is loaded of course, but
remember that the loading causes MapServer to do everything it needs to
do to prepare for the request.

It is my informal impression that the simple text parsing of the map
file goes quite quickly, so efforts toward a "compiled" or "binary" map
file might not help much.  It is the situations where map file parsing
triggers file I/O that seem to be the most expensive, as one would
expect.

A while ago I tended toward creating convenient map files with every
possible layer I could want loaded in there.  Convenient, yes - fast,
no.  Since my applications all have some sort of front end between the
Web client and MapServer, I am now tending towards minimalist map files.
I create MANY map files, each with the minimum set of layers and other
goodies to serve a particular sort of request.  Then my front end
generates a WMS request using the appropriate map file for the current
client request's needs.

	- Ed

Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
ed at topozone.com
(978) 251-4242 

-----Original Message-----
From: UMN MapServer Users List [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On
Behalf Of Frank Warmerdam
Sent: Tuesday, September 19, 2006 9:48 AM
To: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-USERS] Mapfile Tuning

Ed McNierney wrote:
> I have not found that unnecessary projection definitions are 
> expensive, but I certainly agree that minimalist mapfiles will save 
> you a lot of time.

Ed, others,

I think a projection block that provides all the parameters should be
very "cheap" in processing time, but any time you refer to projection
details by EPSG code number, there is a whole file lookup involved.  As
far as I know cost is paid for each EPSG reference, even if many places
refer to the same code.  I would definately like to make some
improvements in this regard, likely within PROJ itself.

It would be interesting to prepare some timetests on this issue to see
just how significant it is.

Best regards,
-- 
---------------------------------------+--------------------------------
---------------------------------------+------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo,
http://osgeo.org