How to speed up the slicing speed?

[ZhiWeiCui]

Thank you so much for such a great project. Fast dynamic maps of large geographic areas is rendered,but the speed is pretty slow too. I want to know is there any way to speed up rendering. Other,between file, s3, and redis, which cache method is faster.

[ezk84]

Depends on your use case, so doing some analysis of where the bottleneck is in your case is the way to go.

I have just spent some time tweaking performance in our case, and I figured pre-simplifying the geometry at lower zoom levels made a huge difference. I ended up using the !PIXEL_WIDTH! SQL parameter to do dynamic pre-simplification and achieved a 4.6x speedup with a negligible rendering fidelity difference. This is because our geometries are very detailed but at low zoom levels, it's best not to ever pull those details out of the DB.

Another technique discussed in #526 is to reduce the amount of geometry being rendered at all at lower zoom levels.

Pre-warming the cache using tegola cache seed will mean you can take the rendering hit ahead of time, so users will only need to wait for tile retrieval from cache. Some notes from my research:

• Using the --bounds param will help speed this up, as the command doesn't try to restrict itself to the bounds set on the map, possibly generating a looot of empty tiles.
• Seeding past zoom level 12 is most likely overkill, most tiles at those zoom levels hardly ever get requested.
• Setting a max-zoom on your map layer (in config.toml) sets the zoom level beyond which no new tiles will be delivered, instead the front end will keep re-rendering the last returned zoom level's tile. Choosing this value should reflect the level at which the full detail of your geometry is visible, after that, more tiles will just cost you rendering time and cache space for no gain.

I have not tried other caching providers than the file cache, so have no performance data to compare. File cache seems to do well enough for our usecase, but would be happy to see some data from anyone else.

[ARolek]

@ezk84 thanks for that great writeup! We really need to add a "best practices" or "performance" section to the tegola docs. There are lots of ways to improve performance on a tileset so it would be great to have a place to collect the various techniques.

[ZhiWeiCui]

@ezk84 Thank you for the detailed answer. It would be better if there were sample code.

My use case:

The heatmap can display the following data:

1. How often the vehicle passes a certain section(this map)
2. Road section real-time congestion(to do)
3. Frequent disconnection of gps device(to do) ...
   This is my heat map by Geoserver and Mapbox GL JS, but I think Geoserver is slow to generate vector tiles(.pbf).

Currently I have two options:

1. Sections heat data is stored in the database. slicing sections of different heat levels from the database, the front end uses mapbox for style configuration. When the heat data changes in the database, I need to re-slice.
2. Slice all sections regardless of heat level. Front-end loading heat data, and then data-driven style of mapbox as https://docs.mapbox.com/mapbox-gl-js/example/data-join/. But I think the data is big, including the id and heat of the sections.

I don't know which scheme is better. Other, I can't agree more with you. I did not find this in the documentation. @ARolek