WMS GetMap with multiple cached layers

[giohappy]

Currently a WMS GetMap request with multiple layers doesn't use GWC cached tiles.

I want to discuss the implementation of this feature for a client of us. The basic idea is the ability to use cached tiles when these are available for one or more of the requested layers.

[simboss]

@nmco can you groom this with @aaime help and then assign it to someone

[aaime]

@giohappy do you have a WMS client hitting GeoServer with the GWC transparent integration enabled? Is it desirable to have this behavior also in WMTS for example? Also, just to be sure, the requested area matches existing tiles, it's just a matter of stacking them one on top of the other, right?

[simboss]

@aaime no, we are hitting standard GS with integrated GWC. Not even hitting GWC directly.

[giohappy]

@aaime our specific use case doesn't require WMTS and, as alreaady said by @simboss , we're hitting GS directly. If you think the implementation should cover more use cases I leave the decision to you and @simboss .

The expected behaviour, from my point of view, is that layers tiles will be stacked the same as without a cache behind them.

[aaime]

Ok, think I got it. Here is a more formal specification before we estimate:

• We want the GWC Direct integration to work also for multi-layer requests matching cacheable raster tiles, in particular:
  • Non raster formats produced by GWC are not going to be considered, e.g., vector tiles, geojson, KML, the only goal is to support raster ones (PNG, JPEG, and the like).
  • If any of the layers in the stack is not cached, or does not match the requested tile and parameters (e.g, custom style, cql filter), a full WMS response will be used
  • Other restrictions might be placed on what activates this mechanism, see considerations below.
• In case the above checks pan out, each tile will be requested to GWC, which will eventually create it if missing. The tiles we get back are encoded PNGs (GWC does not output images, it outputs binary payloads, we'll have to re-parse the encoded output even if the image was generated on the fly)
• All the tiles will be read, stacked on top of each other, eventually color expanded if they are PNG8 (basically no chance they share the same palette) and the output eventually quantized again (if it's PNG8) and encoded in the requested output format.

Some further questions/observations:

• Some of the rasters formats are funky in their own way... do you want support for jpeg-png too? image/geotiff? These two will need dedicated machinery (for each).
• Do we want to support all possible WMS extra parameters that influence caching and can be provided as lists? E.g STYLES (as in, non default styles), CQL_FILTER, FILTER, ENV, VIEW_PARAMS. Or does the code bail out as soon as one of these is found?
• We have no quick way to know if a WMS request corresponds or not to an already available tile or not. If the cache happens to be empty, each tile will be generated, along with the meta-tile containing it, which will cause a potentially long computation time. The response maximum time configured in WMS limits the time it takes to generate a single meta-tile, do we also want to apply a limit here? And return an exception if the process cannot be completed within the limit? Is the limit going to be the same as WMS?
• The whole process described above can be more expensive than rendering from scratch, PNG encoding and decoding are slow, CPU heavy operations. IMHO we should add a new configuration option to enable this behavior... a checkbox is the easiest to add, of course, it won't be optimal for all cases.

[giohappy]

If any of the layers in the stack is not cached, or does not match the requested tile and parameters (e.g, custom style, cql filter), a full WMS response will be used

@aaime does this mean all-or-nothing? Either all the layers have a cache or everything will be rendered from scratch?

[aaime]

No, read again: "In case the above checks pan out, each tile will be requested to GWC, which will eventually create it if missing". The checks mentioned above are to verify that each layer is cacheable at all in the tile requested.

[giohappy]

ok, so "a full WMS response will be used for those layers".

For my specific use case I'm fine with all the resitrctions that you mention (not considering STYLES, CQL, etc.) because this is mainly intended for usage on mobile without the ability to set filters, select styles, and so on.

The following point is not clear to me:

We have no quick way to know if a WMS request corresponds or not to an already available tile or not. If the cache happens to be empty, each tile will be generated, along with the meta-tile containing it, which will cause a potentially long computation time.

Isn't the same process that happens when we have a cache miss with normal, single layer, WMS requests?

[aaime]

There is no "process", we ask GWC to process the request, if it can, it will return a tile, either from cache or freshly computed, if it does not, it means it cannot process it and we do the normal WMS path. What I meant, there is no way to know in advance if a tile corresponding to the request is already in the tile cache, and eventually use the tile composition only if all the needed tiles are already cached (that is, the fastest case).

[giohappy]

I see. The worst case is no tiles cached. In that case doing a direct WMS render would be faster then having to check each layer against GWC (and eventually waiting fot it to create the cached tile). This is the point, right?

[aaime]

It all depends, but yes, depending on the combination of layers involved, the server load, it might happen that building tiles on the fly through WMS is faster than recomposing them from tiles. The worse case is not having the tiles in cache, but even having them, if the source layers are fast enough, having to decode N PNGs might take more time than actually rendering from the data. The thing is, I have no easy way to figure out which case it is, at runtime, it's going to be a "all or nothing", we either recompose tiles crossing fingers, or don't.

[simboss]

Hi @aaime good point.

Not sure @giohappy said this above but the idea is to come up with a mechanism in the TOC of the client(MapStore) where we can control how many layers we coalesce at a time to prevent having the problem you are referring to, plus to have seeding so that we have less cache writes on the most used views.

As an instance, let's say you have a maps with 20 layers (yeah that happens now) I would not go directly for asking tiled GetMaps with 20 layers but I would group them by 3 or so which would still reduce a lot the number of requests we are making and make the client lighter in load on the underlying HW.

[giohappy]

@aaime clearly we have to find a good balance between the number of requests and the number of layers per request, but having this in place will give us the opportunity to tune things depending on the use case (mobile client vs desktop client, number and types of layers, cache configurations, etc.) .

BTW when we have cached tiles I imagine that the overload will always be less then having to hit the DB each time, in partticular when dozens of layers are requested...

[aaime]

Ok, some of the observations/questions I pointed out before have been answered, other ignored... let me try again with a final spec, filling in some blanks, please tell me if it's ok:

• We want the GWC Direct integration to work also for multi-layer requests matching cacheable raster tiles, in particular:
  • Non raster formats produced by GWC are not going to be considered, e.g., vector tiles, geojson, KML, the only goal is to support raster ones (PNG, JPEG, and the like).
  • If any of the layers in the stack is not cached, or does not match the requested tile and parameters (e.g, custom style, cql filter), a full WMS response will be used
  • For the time being, all extra parameters like non default styles, cql_filter, env vars, view params will disable usage of tile stacking and make it fall back on normal WMS
  • For the time being, only the most basic image formats are going to be supported, image/jpeg, image/png, image/png8, support for other raster formats will be added if not too hard (need to look into it)
• In case the above checks pan out, each tile will be requested to GWC, which will eventually create it if missing. The tiles we get back are encoded PNGs (GWC does not output images, it outputs binary payloads, we'll have to re-parse the encoded output even if the image was generated on the fly)
• All the tiles will be read, stacked on top of each other, eventually color expanded if they are PNG8 (basically no chance they share the same palette) and the output eventually quantized again (if it's PNG8) and encoded in the requested output format.
• The overall process with be time limited, using the same WMS time limits (to the user it's a WMS request) and will throw an exception if the operation times out

Sounds good?

[giohappy]

sounds good to me

[giohappy]

After further analysis we noticed that the specifc case use a lot of requests with SQL parameters. This means that these should be included in the spec and caches should be configured to use them. The latter won't be done, at least not soon, so we can freeze this issue for the moment.