May 18 2006

More on Mapnik WMS

Published by perrygeo at 3:38 pm under Python, WMS

One of my initial complaints about the Mapnik WMS server was that it would not accept any parameters that were not in the OGC WMS spec. Some WMS clients will tag on extra parameters for various reasons and the OGC supports this in relation to vendor-specific parameters. The fix was pretty simple;in mapnik/ogcserver/common.py you can simply comment out

#for paramname in params.keys():
# if paramname not in self.SERVICE_PARAMS[requestname].keys():
# raise OGCException(’Unknown request parameter “%s”.’ % paramname)

to get the desired effect.

There was also the question of speed and how it compared to other WMS servers such as Mapserver. Since I already had both a Mapnik and Mapserver WMS set up using the exact same data source, styled in the same fashion, it was pretty simple to write a quick python script that would smack each WMS server with a given number of back-to-back WMS GetMap requests:

#!/usr/bin/env python
import urllib

server = sys.argv[1]
hits = int(sys.argv[2])

if server == 'mapnik':
    url = "http://localhost/fcgi-bin/wms?VERSION=1.1.1&REQUEST=GetMap&SERVICE=WMS&LAYERS=world_borders&SRS=EPSG:4326&BBOX=-4.313249999999993,20.803500000000003,59.58675000000002,52.75350000000002&WIDTH=800&HEIGHT=400&FORMAT=image/png&STYLES=&TRANSPARENT=TRUE&UNIQUEID="
elif server == 'mapserver':
    url = "http://localhost/cgi-bin/mapserv?map=/home/perrygeo/mapfiles/world.map&VERSION=1.1.1&REQUEST=GetMap&SERVICE=WMS&LAYERS=worldborders&SRS=EPSG:4326&BBOX=-4.313249999999993,20.803500000000003,59.58675000000002,52.75350000000002&WIDTH=800&HEIGHT=400&FORMAT=image/png&STYLES=&TRANSPARENT=TRUE&UNIQUEID="

for i in range(0,hits):
    urllib.urlretrieve(url)

Then just run the script from the command line, specifying the server and number of hits, and wrap it in the time command. Here are the results:

Pretty close. Mapserver was just slightly faster in every case. Now this is just a preliminary test and it would be interested to see a comparison:

  • With larger datasets and more complex styling including classification and text labelling
  • With data from other sources such as postgis where the connection overhead might be significant
  • With Mapserver running as a fastcgi
  • With concurrent requests as opposed to back-to-back requests

Overall though, my opinion of Mapnik WMS remains high and I’d love to put it in production use in the near future. Stay tuned…

3 Responses to “More on Mapnik WMS”

  1. # Chris Tweedieon 18 May 2006 at 4:42 pm

    Hi Perry,

    I have been putting off trying out mapnik aswel, the library definately looks good.

    While speed seems to be relatively good in comparison to mapserver, i’m not sure how many people would choose mapnik in a production environment (even with all the bells and whistles of mapserver).

    Looking at your comparison output images, compare the file size mapnik (59kb) vs mapserver (5.9kb). My question … is the nice carto output worth the 10x size increase? In some situations i’d say yes, but overall probably not.

    If only mapnik/agg could be integrated with mapserver just as another outputformat then we’d have the best of both worlds :)

  2. # Sean Gillieson 18 May 2006 at 5:52 pm

    Matt, you should check out the timeit module for benchmarking. There’s an example of it buried in mapserver/mapscript/python/tests. Grep is your friend. Also, force RGB PNGs from MapServer to even out the cost of transporting bytes through urllib. This is another encouraging report; Artem has been telling me for a long time that AGG is no slower than GD.

  3. # Robert Coupon 01 Sep 2006 at 4:50 pm

    Chris, the filesize difference is due to the mapnik output being a 24bit PNG, while the mapserver output is an 8bit PNG. Reducing the mapnik output to 8bit results in a filesize of 15.2KB with no appreciable loss of quality (in that example). It’s still 2 1/2 times the size of the mapserver image though…

Trackback URI | Comments RSS

Leave a Reply