Comment by __turbobrew__ | Hacker News Reader

Comment by __turbobrew__ | Hacker News Reader

Titiler works pretty well for raster data in my experience. It is a step up from using an out of the box solution and involves a bit more development work but pretty easily allows customization. Using titiler on lambda with COGs stored on S3 we could get about 200ms load of a retina resolution map.

We wanted to do things even faster so we started migrating to ECS which when using a network optimized instance we could render a full page map in sub 100ms.

The author states that having all the data in a single file for PMTiles is advantageous, but it is a tradeoff. First of all you cannot modify parts of a S3 file so if you want to modify/update your dataset you need to re-process and re-upload the entire dataset. This can be a real pain if you are working with many TB datasets and you just want to update a subset of the data. Also, I thought that there is a global throughput limit on S3 files so wouldn’t putting all data in a single S3 file potentially hit bottlenecks?

Yes, PMTiles is a tradeoff that isn't appropriate for transactional use cases. SQLite is pretty good for that already.

There is a throughput limit on S3 files of approximately 5500 GETs/sec per key. Bare archives on S3 is an appropriate choice for small-scale, zero maintenance deployments. If your application demands any thing close to that level of throughput, you're probably either:

* Serving individual tiles over the internet: you should use the CDN integration http://protomaps.com/docs/cdn ; most tile requests will be cached and only misses will interact with the S3 bottleneck.

* Bulk accessing a spatial subset of tiles: You shouldn't be requesting HTTP GETs for single tiles, but instead entire subsets of tiles with a single Range request made possible by the internal Hilbert curve ordering. This is still WIP here: https://github.com/protomaps/go-pmtiles/issues/31

> Using titiler on lambda with COGs stored on S3 we could get about 200ms load of a retina resolution map.

Since Lambda presumably has a separate GDAL RAM cache for each request, I'm guessing this wasn't able to take advantage of any of GDAL's header or block caching? It's pretty impressive you were able to get latencies that low with that approach.

The big performance gains of GDAL in this configuration is HTTP2 multiplexing to S3 and TCP keepalives. When a tile request is sent to the lambda tiler it should already have a TCP/TLS connection open to S3 which can then be used to multiplex requests.

That makes sense, thanks!

Reply on news.ycombinator.com