2

I am using MapServer 6 and defining maps with mapfiles.

I have a page where 20 map compositions (~20*5=~100 layers) are possible by varing LAYER/DATA field and some classes of layers... So I can express each map by a mapfile (20 mapfiles) or I can put all layers in the same mapfile... This is the question,

What is better (have better performance), many mapfiles with few layers each, or one mapfile with all (many) layers?

If the answer need some context... I am accessing Mapserver by this URL, where layer names (L1a,L2b) and mapfile name (MFc.map) can vary,

example/cgi-bin/mapserv?LAYERS=L1a,L2b,L3,L4,L5,L6&MAP=MFc.map&FORMAT=image%2Fjpeg&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=epsg:29183&WIDTH=612&HEIGHT=516&BBOX=....

The combinatory is:

  1. Many mapfiles (c=1..20, a=1, b=1..5): a templating software generated 20 mapfiles, each with ~5 layers.

  2. One mapfile (c=1, a=1..20, b=1..5): a templating software can generate a mafile with all ~200 layers.

Improve this question

2 Answers 2

Reset to default
7

The best by far is to use one main mapfile with INCLUDE directives to call other mapfiles (all of them being "simple and specific Map Files" btw). This will definitely speed things up. I tested that and the result is quite impressive. This idea comes from here: http://mapserver.org/es/optimization/mapfile.html

"If you have a complex application, consider using multiple simple and specific Map Files in place of one large ‘do everything’ Map File."

Check this very nice post and blog from Simon, he's a very nice guy working with mapserver and related things: http://smercier1.mapgears.com/blog/?p=37. I used these performance tips and they do work. Here you have another link, but Simon basically explained already that in his blog.

Hope this helps,

Improve this answer
5
  • Hum... To use the INCLUDE directive for including 20 mapfile files, why (??). PS: Simon say nothing about INCLUDE.
    – Peter Krauss
    Commented Jul 17, 2013 at 10:11
  • because it works, at least for me, I edited my answer. I never said that Simon explained that.
    – Gery
    Commented Jul 17, 2013 at 10:24
  • Ok (thanks!), now it makes sense, with your edit and our discussion; but try to be objective for other readers: "the best (...) is to use one main mapfile" is a contradiction with "consider using multiple simple and specific Map Files".
    – Peter Krauss
    Commented Jul 17, 2013 at 10:30
  • (you're welcome) I think you misunderstood that part, one main map file means that other mapfiles will be called from this main map file. Thus this is done to split your one, big, do-everything map file. This means what you quoted recently: consider using multiple simple and specific Map Files", I don't see the contradiction here.
    – Gery
    Commented Jul 17, 2013 at 10:33
  • The title of the question "show directions" to the reader: "many tiny mapfile VS one big mapfiles", so answer is "many" or is "one". Another subject: your mapserver/mapfile link have another issue (!), "Turn off unnecessary layers; the more layers MapServer is displaying, the more time it takes (...) is particularly true of remote WMS".
    – Peter Krauss
    Commented Jul 17, 2013 at 10:38
-1

(this answer is a copy) "Translating" the @Gery answer to "my question language": use many mapfiles.

As Gary showed, the mapfile guide have the answer:

If you have a complex application, consider using multiple simple and specific Map Files in place of one large ‘do everything’ MapFile.

Particularly for remote WMS, as in the question context, another peformance tip, that will speed things up, is to simplify: if there are many layers, "(...) turn off unnecessary layers; the more layers MapServer is displaying, the more time it takes. (...)" (same link).

Do you (reader) have some benchmarking comparing big and tiny mapfiles?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.