Open k0shTm opened 1 year ago
acalcutt
commented
1 year ago you could look at setting the min and max render pool sizes to be closer to your cpu core count. that should make it able to render more in parallel.
https://maptiler-tileserver.readthedocs.io/en/latest/config.html#maxrendererpoolsizes
typically if you are scrolling there are nrw tiles that need to be rendered.
k0shTm
commented
1 year ago @acalcutt thanks for the feedback. I will definitely try that in a couple of hours. But that is a solution for raster tiles. I winder, what do the current map box and map tiler and stadia map services deliver for good map performance? Is it vector tiles or raster tiles with better resolution?
I can also in another attempt to pre render raster tiles in my end if that's required.
Edit: I just tested a couple of free implementation and all are using pbf(vector) and they are fluid enough.
https://www.maptiler.com/maps/#style=streets-v2&mode=2d&position=12.3/40.39965/-3.68106 (somewhat good perf although I can still notice the rendering so not 100% fluid)
https://stadiamaps.com/explore-the-map/#map=8.5/52.0661/-1.1011
Not sure if the mapbox one will work due to the token but the others do. But the mapbox one is certainly the one with better performance.
I'm having a weird behaviour which probably is working as expected.
Even using the webapp on the basic preview, when I move the map a bit faster or zoom in and out, I can see some parts of the map still have the background colour and waiting to be populated/rendered. I have tileserver-gl running on a 32 core server with 128gb of ram and he is chilling with no workload.
Is this problem of the client implementation? Although even on the webapp it still shows these delays. Is there any tune I can do server side as well? According to the app, I average like 1ms per pbf file and I am serving a very small size.
I went through all closed and open issues and I don't see much people complaining about it but I also don't see where I could have failed with this minimal instalation.