options for serving many changing tilesets?

[durkie]

Hello! I love the mbtileserver project and find it very useful. I'm at the point where I'm serving roughly 10,000 different mbtiles files, and they are updated on a mostly random basis (depending on user data uploads). Right now sending SIGHUP to the server takes around 20-25 seconds to refresh all of the tilesets, and the server is unresponsive during that period of time. Ideally I'd be refreshing the tile data every 3-10 minutes or so, so that means 3-13% downtime.

Is there a way that others have dealt with this? As I write this, the idea came to me to run two separate servers or two separate docker containers and SIGHUP them in alternating order so that at least one mbtileserver is responsive at all times, but I don't know how feasible that really is or if there's a better option.

Upstream caching at a CDN is sort of an option, but a little trickier here because the data do change regularly, so actively invalidating tiles becomes the challenge there.

Thanks!

[brendan-ward]

That is an interesting use case and certainly more tilesets than I've been working with on a given server. I imagine that your cold startup of mbtileserver is also around that same time. The time is likely coming from needing to inspect each tileset to gather basic information and check validity.

We are considering a filewatch based reload of tilesets like #78. If we can implement something like this, it should ensure that those tilesets that are updated reload quickly, without needing to reload the others.

What % of the tilesets are updated within a given timeframe? E.g., a few per 10 minute period? Or much more?

Have you run into any memory-related issues with operating that many tilesets?

[durkie]

A filewatch-based setup sounds like it would be really nice. And yes, startup time is about the same amount of time. The percentage of tilesets that are changed at any one time are low. I would say the busiest times have upwards of 10-15 tilesets changing over a 10 minute period, and then many 10-minute periods where maybe 1 changes.

I so far haven't seen many memory related issues, but I've been kind of inching in to full deployment, so it has seen only partial usage in production.

[durkie]

Just to add a bit more color: this has been running for in production now for a week and is super stable running on a 2-core, 4GB VPS. Serving 10,200 tilesets and doing about 1GB of traffic a day. Memory usage is pretty constant at about 2GB, response latencies are almost all <1ms. Thanks for the nice piece of software.

[slachiewicz]

122 implemented fs watch