Tips for serving large tiles in Martin

[jjcfrancisco]

Hi,

We've been running some tests at my company to check Martin's performance. We got good response time at low amount of requests, however, when the amount of requests become larger we noticed that Martin is quicker to fall over than our existing tile server (Mapnik). The type of tiles are fairly large and we are wondering if you have some tips (i.e. specific configs) that could help us with increasing the load performance.

For a bit of context, we used Martin 0.9.3 dockerised.

Many thanks

[nyurik]

@jjcfrancisco thx for reporting, what is the source of tiles you are serving? PostgreSQL/mbtiles/...? What kind of server, connection pool size, etc?

[jjcfrancisco]

Thanks for the speedy reply. The source was postgresql 15 and martin configs is all default for now. We run it on k8s.

[nyurik]

I suspect that the main difference is in the number of simultaneous connections to the PG. We may want to adjust the default - optimize the pool size based on some values like server worker threads or some other magical values... Suggestions welcome. For now, try to play with --workers and --pool-size (see https://maplibre.org/martin/21-run-with-cli.html)

[jjcfrancisco]

Thanks @nyurik. Will hopefully share results when we have them available.

[jjcfrancisco]

After some investigation, we found that the real issue was a simple misunderstanding. Martin performs MVT transformations (i.e. ST_AsMVT or ST_AsMVTGeom) at the database level whereas Mapnik does it in-house. When testing Martin we noticed a considerable increase on the virtual machine's CPU. Bumping up resources fixed the issue.

I made a PostGIS function following this example but I managed to ignore that such function implies PostGIS doing the MVT jobs 😅

Having said that, it'd be nice if at some stage there was an option to get Rust to do the MVT jobs. My impression is that this may become a reality in the future?

Thanks for the help @nyurik

[nyurik]

Yes, I have received some requests for that functionality. I'm all in favor of doing it at some point, just wish I had more time to work on it... in the mean time, I will be glad to review any such code contribution :)