IIIF Manifest generation is slow -- consider caching canvas height/width?

[benwbrum]

We've installed Islandora 8 with the Paged Content module and are running into performance problems generating manifests: a Paged Content node with 60-200 Page children takes several seconds (or even minutes) to respond with to node/{id}/manifest requests, but seems to respond correctly when it does.

Our theory is that this slowness is due to the need to calculate the width and height attribute values for each canvas -- apparently this is done by asking Cantaloupe for an image's dimensions, which would certainly take a long time.

We'd like to propose caching either the generated manifests or at least the height/width attributes for each child node.

We're new to Drupal development, but are happy to pitch in on the development with some guidance. If there's a better way to approach the performance issue, we're all ears.

[seth-shaw-unlv]

You should be able to turn on caching on a per-view basis. Whether or not we should turn it on by default is another question...

[saracarl]

@seth-shaw-unlv The iiif manifest view already has caching turned on by default. It's tag based caching. I can't tell what tags it uses, but I imagine node based would be appropriate (and perhaps what's being used?).

[whikloj]

Is a second access of the same resource significantly faster? If so, perhaps some sort of cache warming would be of benefit 🤷‍♂

[saracarl]

@whikloj I agree, it does seem faster after the first load, so the caching does seem to be happening. We noticed this at a time where we were ingesting/rolling back/ingesting/rolling back so it was always slow, but I think the 2nd load is reasonable.

Cache warming would make sense.