Hi again, I've now moved to an 8-core VM with 32Gb of RAM, which has made certain operations faster, but processing the stylesheets and beginning rendering still seems to be very slow.
Some numbers: from the moment I hit 'save' at zoom 13 in the centre of Melbourne: 1. at 1:05 , the spinning icon stops (I assume this means the stylesheets have been saved and processed) 2. at 2:15, the first tile appears 3. at 2:35, all visible tiles are rendered . During this process, there's almost no database activity - all queries are handled very quickly. Turning off every layer (so just rendering background-color): 1 0:48, spinning icon stops (tilemill-ui at just over 100% until now) 2. 1:45, first tile appears, (tilemill-tile around 100% until now). 3. 1:46 all tiles This cluster has had problems with slow file I/O in the past, so wonder if that's the likely result? By contrast, a simple project with simple stylesheet saves and renders almost instantly (<1s). The styles are here: https://github.com/stevage/stevebikemap What I'd love to know: 1) What is happening for the first 50 seconds? Does TileMill really take that long to parse 5 smallish stylesheets and convert them into mapnik styles? If it sounds like a bug, I'm happy to investigate further... 2) What exactly is happening in step 2? I don't know Mapnik at all, so I'm just guessing that it's doing pre-computation like loading all the objects and their styles, computing z-orders, resolving conflicts between labels etc. Still this seems slow? 3) Why is step 2 so slow even when every layer is invisible? 4) Is there any way to increase the number of threads/processes, to get more advantage from the 8 cores? Hmm, with further investigation, it seems almost all the time is going into the 'areas.mss' style. Commenting it out reduces the whole save/render cycle to just 7 seconds (from 155!) As an example: #areas[zoom>13][leisure="pitch"], #areas[zoom>13][leisure="golf_course"], #areas[zoom>13][landuse="cemetery"] { line-color:darken(green,5%); line-width:1; line-opacity:0.2; polygon-fill:#bdb; } Rendering that one rule takes an additional 7 seconds (ie, 14 seconds instead of 7, including saving/processing time), even at zoom 13, when it's not even being applied. Making the #areas layer invisible had no effect on rendering time. I guess I can further decompose these db queries (#landuse, #leisure...), but is there anything else I can do to speed them up? Is this normal? Thanks again for any information, Steve On Wed, Feb 27, 2013 at 10:03 PM, Steve Bennett <stevag...@gmail.com> wrote: > Hi, > (First - is this the right list to discuss using TileMill? I can > only find the MapBox support form, or gis.stackexchange.) > > I'm having some problems with TileMill rendering very slowly. > Sometimes it seizes up altogether, until I restart it or reboot the > server. This seems to happen particularly when I frequently interrupt > rendering by saving the stylesheet again. > > My setup is a 2-core, 8Gb Ubuntu VM running on an OpenStack cluster. > PostGIS (with Melbourne city data from bbbike.org), nginx for auth, > and one shapefile. Pretty vanilla. > > I have a few questions about how to improve speed in TileMill/Mapnik: > 1) In general, what kinds of rendering rules are slow? Does the way > you specify a rule affect the speed? (eg, is [zoom>13] { #ways[...] } > slower/faster than #ways[...][zoom>13] ?) > 2) How does caching take place? It seems to me that when saving a > stylesheet with changes, there's a long delay before anything renders, > then subsequent small changes aren't too slow. So some layers are > computed once then reused? > 3) Are there any easy tips for tuning the database? > 4) Or tuning TileMill/Mapnik? > 5) Watching 'top' during a render, it doesn't look like much memory is > being used. Is there a way to trade memory for speed? > 6) Does setting a layer invisible definitely prevent it being > computed? Sometimes I think I'm going mad... > 7) Lastly,will adding cores lead to a proportional increase in speed? > > Thanks very much in advance, > Steve _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
