Just a quick note. Many years ago I started rendering my maps in batches. Then I found out that to increase speed, 
[I  could use metatiles](https://www.grulic.org.ar/~mdione/glob/posts/writing-a-tile-server-in-python/). 
I found that 8 was a good size.

Now [I developed a rendering tile server](https://www.grulic.org.ar/~mdione/glob/posts/writing-a-tile-server-in-python/), 
which means I can query for tiles, and if they hagve not been redered yet, they
can be rendered on the fly. But now the requirements changed. When rendering batches, I can keep the rendering
pipeline busy because there's always another metatile to render (unless I'm at the end of the batch), so all the
threads are always busy. But with such a big metatile, the latency is terrible. It's not a problem because I'm, not 
consuming the tiles immediately.

With the rendering tile server, I do care about latency. Those big metatiles can take several seconds to render,
and as a user I don't want to wait that long to see the map. Also, because the client can see at most 4
metatiles, but usually just 1 or 2, the rest of the threads are sitting idle. So by reducing the metatile
size to 2, I can reduce the latency by parallelyzing more. Granted, each individual tile takes more time to
render in average, but the service becomes more snappy. So far a metatile size of 2 has proven good enough;
I don't think I'll ever try with 1.