Martin v0.11.6 much faster than v0.12.0 and 0.13.0??

[nyurik]

Martin v0.11.6 much faster than v0.12.0 and 0.13.0??

[ShadowSonata]

I had this similar issue the other day (as I was using the tag latest for my testing and it automatically bumped to the latest version). I found out that the content-encoding has changed.

This is the response header in v0.11.6

And the response header in v0.13.0

If I force content-encoding to gzip by adding "Accept-Encoding" to my request, the response time and the data size come back to normal.

[nyurik]

@ShadowSonata I think that's the culprit. I switched the default serving compression from gzip to brotli encoding (when the browser supports both and has not set a preference of one over the other). As you can see from your own example, you gained 20% on the content size. But that 20% doesn't come from nowhere - Brotli takes longer to compress.

So there are two ways to fix this, and both in theory could be used:

• add compression preference, e.g. a CLI param --preferred-encoding (gzip|brotli) and a similar global config file value. If the browser does not give different q values for br and gzip in the Accept-Encoding header, Martin will pick one over the other. By default, Chrome sets Accept-Encoding:gzip, deflate, br (default q=1.0 for all)
  • #1178
• Martin tile cache contains pre-compressed values - i.e. the cache has the value as returned by the tile source. MBTiles usually stores gzipped tiles. Postgres usually returns uncompressed ones. This means that Martin compresses tiles on each response when tiles are coming from Postgres. The solution is to modify cache logic to store the tile after compressing it. This will make responses much faster except for the very first one (per tile coordinates).
  • #1112

[nyurik]

The individual issues #1178 and #1112 track both of the use cases. It should be fairly easy to do - and as always, I am more than willing to guide any newcomers if someone can step forward before I get to it in my limited volunteer time. Thx!